La Conduite Du Changement

Nom : LEPICOUCHE Prnom : Audrey M2IRT 2007 TER
Mmoire 2007 Quelle est la conduite suivre sur le management du projet, lorsquun changement intervient durant un projet informatique ?
Version finale
Quelle est la conduite suivre sur le management du projet, lorsquun changement intervient durant un projet informatique ?
Audrey LEPICOUCHE
2007
1.
1.1
Rsum / Abstract et remerciements

Rsum
Les projets informatiques sont des projets omniprsents dans toutes les socits actuelles. Linformatique est en continuel changement, ou plus exactement en continuelle volution, ce qui implique que les socits soient amenes faire voluer leur systme dinformation en fonction des volutions de linformatique. Ces volutions se font par le biais de projet que soit les socits traitent elles-mmes, soit quelles font sous-traits. Dans les deux cas, la gestion dun projet reste la mme 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 voqus dans ce mmoire, le management humain, technique, commercial, financier et le management de production. Chaque domaine de management est spcifique et doit tre trait diffremment. En effet, un changement dans le management humain ne se traitera pas de la mme manire quun changement dans le management commercial. Pourtant, cela sera la mme 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, lorsquun changement intervient durant un projet informatique ? Il est donc important dexpliquer dans un premier temps, les diffrents managements existant dans la gestion de projet informatiques. Dans un second temps, il faut faire une analyse de lexistant et mettre en vidence les points ngatifs des conduites suivies pour faire face aux changements. Par la suite, il faudra voquer les amliorations qui peuvent tre faites et les solutions mettre en place pour rpondre ces amliorations.
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.
La conduite de changement de management de projets informatique
Page 2 / 79
Audrey LEPICOUCHE
2007
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 mmoire, Thierry CRAYE, de mavoir guid et mise sur la bonne voie pour la rdaction de ce mmoire. Je le remercie, de mavoir clair et de mavoir aid clarifier et prcis le sujet de ce mmoire. Je souhaite galement le remercier pour les diffrents conseils quil ma adresss et qui mont permis de rdiger ce mmoire et de comprendre les enjeux de ce sujet. Je voulais galement remercier lITIN et plus particulirement Cline VITHE qui a su me conseiller et me soutenir tout au long de la rdaction de ce mmoire. Enfin je tiens remercier les personnes qui ont bien voulu maccueillir et maccorder de leur temps afin de rpondre aux questions que javais prparer pour traiter ce sujet.
Page 3 / 79
Audrey LEPICOUCHE
2007
2.
1.
Table des matires

RESUME / ABSTRACT ET REMERCIEMENTS ............................................................................. 2
1.1 1.2 1.3 2. 3.
RESUME....................................................................................................................................... 2 ABSTRACT .................................................................................................................................... 2 REMERCIEMENTS ........................................................................................................................... 3
TABLE DES MATIERES............................................................................................................. 4 DEFINITION DU SUJET ............................................................................................................ 7 3.1 3.2 DEFINITION .................................................................................................................................. 7 QUESTIONS FONDAMENTALES ......................................................................................................... 8
4.
ANALYSE DE LEXISTANT ........................................................................................................ 8 4.1 ENVIRONNEMENT .......................................................................................................................... 9 4.1.1 QUEST-CE QUUN 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 LEXISTANT ............................................................................................... 14 4.2.1 LA CONDUITE SUIVIE LORS DUN 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 DUN CHANGEMENT TECHNIQUE ............................................................. 18 4.2.2.1 LANGAGE DE PROGRAMMATION ............................................................................................. 19 4.2.2.2 ARCHITECTURE RESEAUX........................................................................................................ 20 4.2.2.3 SYSTEME DEXPLOITATION ..................................................................................................... 20 4.2.3 LA CONDUITE SUIVIE LORS DUN 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 DUN 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 DUN 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 LEXISTANT ............................................................................................................... 27
Page 4 / 79
Audrey LEPICOUCHE 4.3.1 4.3.1.1 4.3.1.2 4.3.1.3 4.3.1.4 4.3.2 4.3.2.1 4.3.2.2 4.3.2.3 4.3.3 4.3.3.1 4.3.3.2 4.3.4 4.3.4.1 4.3.4.2 4.3.4.3 4.3.5 4.3.5.1 4.3.5.2 5. 6.
2007
LA CONDUITE SUIVIE LORS DUN CHANGEMENT HUMAIN ................................................................. 27 CHEF DE PROJET ................................................................................................................... 27 COLLABORATEUR.................................................................................................................. 28 LES ARRETS MALADIE ............................................................................................................ 28 LES CONGES PAYES ............................................................................................................... 29 LA CONDUITE SUIVIE LORS DUN CHANGEMENT TECHNIQUE ............................................................. 29 CHANGEMENT DE LANGAGE DE PROGRAMMATION..................................................................... 29 CHANGEMENT DARCHITECTURE RESEAU .................................................................................. 30 CHANGEMENT DE SYSTEME DEXPLOITATION ............................................................................. 30 LA CONDUITE SUIVIE LORS DUN CHANGEMENT COMMERCIAL .......................................................... 31 MODIFICATION DE PERIMETRE ................................................................................................ 31 AVENANTS AU CONTRAT ........................................................................................................ 31 LA CONDUITE SUIVIE LORS DUN CHANGEMENT FINANCIER .............................................................. 32 RESTRICTIONS BUDGETAIRES .................................................................................................. 32 DEPENSES IMPREVUES........................................................................................................... 33 RACHAT DE LA SOCIETE .......................................................................................................... 33 LA CONDUITE SUIVIE LORS DUN CHANGEMENT EN PRODUCTION ...................................................... 33 PRODUIT FINAL NON FONCTIONNEL ......................................................................................... 33 ARCHITECTURE CLIENTE MODIFIEE ........................................................................................... 34
METHODES ET DEMARCHES UTILISEES.................................................................................. 35 DESCRIPTION DES AMELIORATIONS ..................................................................................... 39 6.1 AMELIORATIONS SOUHAITABLES..................................................................................................... 39 6.1.1 LES AMELIORATIONS A APPORTER LORS DUN 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 DUN CHANGEMENT DANS LE MANAGEMENT TECHNIQUE .......... 42 6.1.2.1 CHANGEMENT DE LANGAGE DE PROGRAMMATION..................................................................... 42 6.1.2.2 CHANGEMENT DARCHITECTURE RESEAU .................................................................................. 43 6.1.2.3 CHANGEMENT DE SYSTEME DEXPLOITATION ............................................................................. 44 6.1.3 LES AMELIORATIONS A APPORTER LORS DUN CHANGEMENT DANS LE MANAGEMENT COMMERCIAL ....... 44 6.1.3.1 MODIFICATION DE PERIMETRE ................................................................................................ 44 6.1.3.2 AVENANTS AU CONTRAT ........................................................................................................ 45 6.1.4 LES AMELIORATIONS A APPORTER LORS DUN CHANGEMENT DANS LE MANAGEMENT FINANCIER ........... 46 6.1.4.1 RESTRICTIONS BUDGETAIRES .................................................................................................. 46 6.1.4.2 DEPENSES IMPREVUES........................................................................................................... 47 6.1.4.3 RACHAT DE LA SOCIETE .......................................................................................................... 47 6.1.5 LES AMELIORATIONS A APPORTER LORS DUN CHANGEMENT DANS LE MANAGEMENT DE PRODUCTION ... 47 6.1.5.1 PRODUIT FINAL NON FONCTIONNEL ......................................................................................... 48 6.1.5.2 ARCHITECTURE CLIENTE MODIFIEE ........................................................................................... 48 6.2 SOLUTIONS POSSIBLES .................................................................................................................. 49 6.2.1 LES SOLUTIONS POSSIBLES POUR AMELIORER LA GESTION DE PROJET ................................................. 49 6.2.1.1 LA DOCUMENTATION ............................................................................................................ 49 6.2.1.2 UTILISATION DE LA DOCUMENTATION ...................................................................................... 50 6.2.1.3 GESTION ET STOCKAGE DE LA DOCUMENTATION ........................................................................ 50 6.2.1.4 LES DIFFERENTES REUNIONS ................................................................................................... 51 6.2.1.5 LA COMMUNICATION PAR MESSAGERIE .................................................................................... 52 6.2.2 LES SOLUTIONS POSSIBLES LORS DUN CHANGEMENT DANS LE MANAGEMENT HUMAIN ........................ 52 6.2.2.1 COMPOSITION DE LEQUIPE PROJET ......................................................................................... 53
Page 5 / 79
Audrey LEPICOUCHE
2007
6.2.2.2 LA PLANIFICATION ................................................................................................................ 54 6.2.3 LES SOLUTIONS POSSIBLES LORS DUN CHANGEMENT DANS LE MANAGEMENT TECHNIQUE .................... 55 6.2.4 LES SOLUTIONS POSSIBLES LORS DUN CHANGEMENT DANS LE MANAGEMENT COMMERCIAL ................. 56 6.2.5 LES SOLUTIONS POSSIBLES LORS DUN CHANGEMENT DANS LE MANAGEMENT FINANCIER ..................... 57 6.2.6 LES SOLUTIONS POSSIBLES LORS DUN CHANGEMENT DANS LE MANAGEMENT DE PRODUCTION ............. 57 6.3 CHOIX DES SOLUTIONS DAMELIORATION ......................................................................................... 58 6.3.1 LA GESTION DE PROJET.............................................................................................................. 59 6.3.2 LE MANAGEMENT HUMAIN ........................................................................................................ 59 6.3.3 LE MANAGEMENT TECHNIQUE .................................................................................................... 60 6.3.4 LE MANAGEMENT COMMERCIAL ................................................................................................. 60 6.3.5 LE MANAGEMENT FINANCIER ..................................................................................................... 61 6.3.6 LE MANAGEMENT DE PRODUCTION ............................................................................................. 61 6.4 ARGUMENTATION ET JUSTIFICATION DU CHOIX ................................................................................. 61 6.4.1 LA GESTION DE PROJET.............................................................................................................. 62 6.4.2 LE MANAGEMENT HUMAIN ........................................................................................................ 63 6.4.3 LE MANAGEMENT TECHNIQUE .................................................................................................... 64 6.4.4 LE MANAGEMENT COMMERCIAL ................................................................................................. 64 6.4.5 LE MANAGEMENT FINANCIER ..................................................................................................... 64 6.4.6 LE MANAGEMENT DE PRODUCTION ............................................................................................. 65 6.5 DESCRIPTION DETAILLEE DE LA SOLUTION CHOISIE ............................................................................. 65 6.5.1 LA GESTION DE PROJET.............................................................................................................. 65 6.5.1.1 LA DOCUMENTATION ............................................................................................................ 65 6.5.1.2 UTILISATION DE LA DOCUMENTATION ...................................................................................... 66 6.5.1.3 GESTION ET STOCKAGE DE LA DOCUMENTATION ........................................................................ 67 6.5.1.4 LES DIFFERENTES REUNIONS ................................................................................................... 68 6.5.1.5 LA COMMUNICATION PAR MESSAGERIE .................................................................................... 68 6.5.1 LE MANAGEMENT HUMAIN ........................................................................................................ 69 6.5.2 LE MANAGEMENT TECHNIQUE .................................................................................................... 70 6.5.3 LE MANAGEMENT COMMERCIAL ................................................................................................. 70 6.5.4 LE MANAGEMENT FINANCIER ..................................................................................................... 71 6.5.5 LE MANAGEMENT DE PRODUCTION ............................................................................................. 71 7. PROCESSUS DE CHANGEMENT ............................................................................................. 72 7.1 7.2 7.3 8. 9. 10. 11. 12. 13. 13.1 13.2 14. DESCRIPTION DU PROCESSUS ......................................................................................................... 72 MISE EN PLACE DES AMELIORATIONS............................................................................................... 73 DIFFICULTES RENCONTREES ........................................................................................................... 73
SYNTHESE DES RESULTATS ET APPORT DU TRAVAIL .............................................................. 74 ENSEIGNEMENTS TIRES........................................................................................................ 75 CONCLUSIONS GENERALES ............................................................................................... 76 BIBLIOGRAPHIE ................................................................................................................ 77 WEBOGRAPHIE................................................................................................................. 77 TERMINOLOGIE ................................................................................................................ 77 ABREVIATIONS......................................................................................................................... 77 GLOSSAIRE.............................................................................................................................. 77 ANNEXES ......................................................................................................................... 78
REPONSES AU QUESTIONNAIRE ELABORE POUR LES INTERVIEWS ..................................................................... 78
Page 6 / 79
Audrey LEPICOUCHE
2007
3.
Dfinition du sujet
Le sujet prsent dans ce mmoire est Quelle est la conduite suivre sur le management du projet, lorsquun changement intervient durant un projet informatique ? .
3.1
Dfinition
Le point principal de ce sujet est la conduite de changement prcis par la suite avec un certain type de changement qui est le management, dans une situation prcise, savoir les projets informatique. Le management de projets informatique sexerce dans plusieurs domaines : le ct technique des projets, le ct commercial, financier, humain et le management au niveau de la production. La conduite suivre lors dun changement de management dans un projet est diffrente selon le domaine. La conduite ne sera pas la mme si cest un changement de management au niveau du personnel ou au niveau technique ; cela ne se gre pas de la mme manire. Il est donc important dans un premier temps de comprendre et danalyser les diffrents domaines de management. De plus, dans ce mmoire 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 sattarder sur ce que sont des projets informatiques et comment sont grs de tels projets. Dans ce mmoire, il nest pas question de sattarder sur la conduite du changement pour mener bien un projet informatique mais de sattarder plutt sur la conduite suivre lorsquun problme apparat durant un projet. Pour tre plus prcis, la conduite suivre, avant le commencement dun projet informatique impactant un changement, est dobtenir les besoins, analyser les impacts que cela va avoir sur le systme dinformation de la socit, faire de la communication auprs du personnel afin que le projet soit accept du mieux possible Dans ce mmoire, nous ne considrons pas toute cette partie avant projet . En effet, dans notre cas le projet a dj commenc et notre but est de trouver des solutions si un changement, prvu et plus particulirement si non prvu, intervient durant le droulement du projet informatique. Il est noter que les conduites suivre ne sont pas les mmes selon le type de management ou mme le type de projet. Mais il ne faut pas oublier un point essentiel du mmoire : le changement. En effet, il existe diffrents types de changement qui peuvent apparatre dans un projet informatique comme un changement des besoins du client, un changement de collaborateurs Ces diffrents 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 lments vont permettre de trouver des solutions rpondant au sujet du mmoire. Il est donc important dapporter des solutions pour les diffrents types de management et seulement selon certains types de changement et certains types de projets informatiques car ces derniers sont beaucoup trop diversifis pour pouvoir tous les tudier.
Page 7 / 79
Audrey LEPICOUCHE
2007
3.2
Questions fondamentales
La question fondamentale, dans ce sujet, est Quelle est la conduite suivre sur le management du projet, lorsquun changement intervient durant un projet informatique ? Cette question est vaste puisque plusieurs rponses peuvent y tre apportes. Ce sont notamment ces rponses qui seront trouves tout au long de ce mmoire. En effet, comme il a t expliqu dans le paragraphe de prcdent, plusieurs rponses peuvent tre apportes cette question car elle porte sur des domaines de management diffrents, technique, commercial, financier et il faut donc trouver des solutions pour chacun des domaines. Ainsi cinq questions se dclinent de la question fondamentale, chacune de ces questions portant sur un domaine de management diffrent comme : Quelle est la conduite suivre sur le management technique du projet, lorsquun changement intervient durant un projet informatique ?, ou Quelle est la conduite suivre sur le management financier du projet, lorsquun changement intervient durant un projet informatique ? Dautres questions viennent galement prciser la question fondamentale, avec notamment des prcisions concernant les types de changement. Cela donne comme question : Quelle est la conduite suivre sur le management technique du projet, lorsquun changement des besoins du client intervient durant un projet informatique ?, ou Quelle est la conduite suivre sur le management humain du projet, lorsquun changement de collaborateur intervient durant un projet informatique ? Par consquent, 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 diffrentes questions ne sont pas toutes crites dans ce paragraphe mais les diffrents types de management et de changement seront numrs dans le paragraphe suivant. Il est donc noter quil y a une question par type de management avec pour chacun deux des questions qui se dclinent 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 lenvironnement tournant autour de ce sujet. Il vous sera donc prsent dans le prochain paragraphe une analyse de lexistant dans le domaine de la conduite suivre sur le management dun projet informatique lorsquun changement intervient.
4.
Analyse de lexistant
Page 8 / 79
Audrey LEPICOUCHE
2007
Aprs avoir bien dfini le sujet et avoir bien compris les questions fondamentales qui se posent dans ce mmoire, le travail consiste faire lanalyse de lexistant en prcisant le contexte, lenvironnement du sujet.
4.1
Environnement
A lheure actuelle, toutes les socits sont dotes de linformatique pour grer leur systme dinformation. En effet, bien que le support papier restent, dans certains cas, obligatoire, ces derniers sont mis sous formes lectroniques afin dassurer la socit un gain de place et de temps. En revanche, linformatique est en constante volution et demande ainsi beaucoup de modifications pour quune socit soit constamment jour, cest linnovation. Par exemple, il faut fournir aux employs dune socit, la dernire version dun logiciel sur leur poste de travail afin de ne pas se retrouver avec des fichiers non lisibles d une version trop vtuste, il faut galement toujours veiller ce que la scurit informatique de la socit soit dactualit, comme mettre jour les anti-virus . Ces modifications peuvent entraner de grands changements dans le systme dinformation dune socit pouvant provoquer dans des cas extrmes un arrt total de la production. Pour viter ce type de dsagrment, il est important que toutes modifications impactant le systme dinformation dune socit soient traites en mode projet permettant ainsi de mettre en place des solutions prventives face au changement.
4.1.1 Quest-ce quun projet informatique ?

Plusieurs dfinitions peuvent tre donnes au terme Projet . Dans ce mmoire, ce terme sera dfini selon deux organismes : lAFNOR qui est lassociation franaise de normalisation et lAFITEP qui est lassociation francophone de management de projet. La dfinition dun projet selon lAFNOR* (Norme X50 105 / Aot 1991) est la suivante : Le projet est un processus unique qui consiste en un ensemble dactivits coordonnes et matrises, comportant des dates de dbut et de fin, entrepris dans le but datteindre un objectif conforme des exigences spcifiques, incluant des contraintes de dlais, de cots et de ressources . Cette premire dfinition montre bien, quun projet est un vnement important au sein dune socit puisquil implique des contraintes ; non seulement des contraintes de cots mais galement de ressources. En effet, il faut mettre disposition du personnel afin que le projet soit men bien et dans les dlais. Tout ceci a bien entendu un cot pour la socit. Il est galement important de coordonner un projet afin quil soit termin dans les dlais et quil soit de plus matris afin dviter labandon du projet. La dfinition dun projet selon lAFITEP* est la suivante :
Page 9 / 79
Audrey LEPICOUCHE
2007
Le projet est un ensemble dactions raliser avec des ressources donnes, pour satisfaire un objectif dfini, dans le cadre dune mission prcise, et pour la ralisation desquelles on a identifi non seulement un dbut, mais aussi une fin . Cette seconde dfinition fait paratre un autre aspect important du terme projet , elle montre quil est essentiel de bien prparer un projet, quil est important de faire des plans dactions au commencement du projet afin que celui-ci aboutisse ses objectifs. Un projet est donc innovateur, puisquil est unique et consiste atteindre des objectifs selon les besoins dun client ; ces besoins tant bien entendu innovateurs pour le client. Ce mmoire tant tourn vers le monde de linformatique, il est important de parler des projets informatique. Un projet de type informatique permet de sassurer, dans la plupart des cas, que les modifications faites sur le systme dinformation, par le biais de ce projet, ne provoqueront pas de soucis sur les activits de la socit. Un projet a pour but danalyser lexistant et de lister les impacts que peuvent avoir des modifications sur le systme dinformation. Ainsi les projets permettent de prvenir des risques et de trouver les solutions adquates afin de faire les modifications sans impacts lourds pour la socit. Mais bien que des prcautions soient prises en amont du projet, durant ce dernier, le chef de projet nest pas labri dun changement imprvu. Le chef de projet, devant garantir le bon droulement du projet, doit sassurer davoir des solutions pour palier aux ventuels changements inattendus.
4.1.2 Les types de management

Selon lencyclopdie multimdia Wikipdia, le management est la gestion dun groupe pour la ralisation dun objectif . Cette dfinition se rapproche trs nettement de la dfinition dun projet. Il en ressort donc que le management est au cur des projets en gnral. Le management de projets informatique sexerce dans plusieurs domaines : le ct technique des projets, le ct commercial, financier, humain et le management au niveau de la production. Dans ce mmoire, ces diffrents domaines seront donc qualifis comme des types de management que nous allons expliquer.
4.1.2.1
Le management humain
Le management humain est la base de toute socit. Sans ressources humaines, une socit ne peut pas exister. Pour un projet informatique, le problme est le mme, sans ressources humaines, il nest pas possible quun projet prenne forme. Comme il a t dit prcdemment, le management est au cur des projets. Le management humain est sans doute un des lments vital du bon droulement dun projet. Sans management, il ny a pas de coordination et pas de matrise. Sans coordination et sans matrise, il ny a pas de projet. Un projet doit tre coordonn au niveau humain. Le chef de projet a ainsi plusieurs lments mettre en place : La conduite de changement de management de projets informatique Page 10 / 79
Audrey LEPICOUCHE
2007
Il faut quil constitue son quipe projet en recrutant des personnes ayant les comptences requises afin que le projet puisse avancer mais galement en tenant compte du budget qui a t prvu. Il faut quil prvoie des formations pour ces collaborateurs si ces derniers nont pas les comptences techniques ncessaires en tenant toujours compte du budget. Il faut quil planifie son projet en tenant compte des soucis ventuels tels que les arrts maladies, les congs pays, les incompatibilits dhumeur entre les collaborateurs, les dmissions
Le moindre changement au niveau du management humain pourrait avoir des consquences ngatives sur le bon droulement dun projet informatique. Les solutions qui seront trouves 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 prsent dans tous les types de projet. En effet quelque soit le type de projet informatique quune socit souhaite entreprendre, il y aura obligatoirement une partie technique pour dvelopper le projet. Que se soit un projet de type dveloppement web , ou de type dveloppement dun progiciel ou de type migration dun rseau vers un autre site, il est ncessaire de prvoir dans le projet une partie technique. Cette partie technique se traduira soit par des langages de programmation, ou par une refonte du plan dadressage IP dun rseau informatique. Il est donc important pour le chef de projet deffectuer du management dun point de vue technique. Cest dire quil faut que le chef de projet sattarde sur les aspects techniques afin de bien dterminer les comptences mettre en uvre pour mener bien son projet. Il faut quil dfinisse le plus prcisment possible les points techniques faciles mettre en uvre et ceux qui peuvent reprsenter des risques. Le moindre changement au niveau du management technique pourrait avoir des consquences ngatives sur un projet. Cela pourrait remettre en cause le planning et par consquent les dlais du projet. Les solutions trouves durant ce mmoire permettront de comprendre comment faire face ce type de changement.
4.1.2.3
Le management commercial
Le management commercial est un aspect trs diffrent des types de management vus prcdemment. En effet, ce management est trs important pour que le projet soit men bien mais ce type de management ne touche pas forcment toute lquipe projet, il va particulirement toucher le chef de projet. En effet ce dernier va avoir un rle commercial auprs de son client afin de vendre au mieux les diffrents aspects du projet. Aprs avoir tabli pour le client une rponse lappel doffre, il y a toujours des dtails commerciaux affiner comme par exemple les outils utiliser qui peuvent coter plus ou moins cher. Mais la participation du chef de projet dans la partie commercial va surtout se traduire sur
Page 11 / 79
Audrey LEPICOUCHE
2007
des aspects tels que les pnalits 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 droulement du projet mais pas forcment pendant la signature du contrat, bien que cela dpend de lorganisation de la socit ayant dcroch le contrat. En effet les socits de type TPE*, compares aux grandes entreprises, nont pas forcment les moyens davoir un commercial et un chef de projet. Bien souvent une seule et mme personne endosse les deux rles. Le moindre changement au niveau du management commercial pourrait avoir des consquences sur le bon droulement du projet. Cela pourrait notamment engendrer une perte au niveau financier et ainsi provoquer labandon du projet. Ce mmoire permet de prsenter les solutions pour palier ce type de changement.
4.1.2.4
Le management financier
Le management financier dun projet est trs important. Comme tout management financier, cest lui qui permet de faire vivre ou non une socit, des projets ... En effet, le financement dun projet va permettre au chef de projet de constituer son quipe, mais galement de se procurer les lments ncessaires la mise en uvre du projet comme les machines, les outils de dveloppement, les supports pour les livrables Sans financement un projet ne peut pas exister. Par consquent il est important pour le chef de projet, de faire de la gestion des finances attribu au projet. En effet, il nest pas judicieux de tout dpenser ds le dbut du projet, ou mme de vouloir faire des conomies au dpend du bon droulement 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 dappliquer une bonne conduite pour mieux apprhender le changement.
4.1.2.5
Le management de production.
Le management de production est le dernier type de management qui sera prsent dans ce mmoire. Ce type de management survient durant la phase finale du projet. En effet la production dun projet informatique se traduit le plus souvent par la mise en place chez le client du logiciel dvelopp, ou par le basculement dun site un autre du rseau de lentreprise. Le management de production consiste donc mettre en place les lments ncessaires afin que cette mise en production de fasse de manire transparente et sans accrocs pour le client. Ce management demande beaucoup de prparation mais galement de tests prliminaires afin dviter des interruptions totales de services chez le client pour les cas extrmes. Le chef de projet est donc en charge de planifier au mieux cette mise en production.
Page 12 / 79
Audrey LEPICOUCHE
2007
Un changement intervenant durant la mise en production chez le client du projet pourrait avoir des consquences 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 dfinition du sujet (3.1), les types de changement composent les diffrents types de management vus prcdemment. Dans ce paragraphe concernant les types de changement, ces derniers seront prsents en fonction du type de management auquel ils appartiennent.
4.1.3.1
Les changements dans le management humain
Les diffrents changements pouvant survenir dans le management humain sont nombreux. Ils ne seront pas tous voqus car la liste serait trop longue. Ce mmoire va donc sattarder sur des changements tels que le remplacement du chef de projet, le dpart dun collaborateur ou plus exactement dune personne de lquipe projet. Il y a galement des changements tels que les congs pays ou mme les arrts 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 lorigine de dpassement de dlai dans un projet informatique. Ces consquences ngatives, qui peuvent entraner des pnalits financires voire labandon du projet, sont souvent provoques par des changements technologiques tels que des changements de langage de programmation, de systme dexploitation, doprateur ou darchitecture dans le cas de projets bass sur le rseau.
4.1.3.3
Les changements dans le management commercial
Les changements dans le management commercial sont diffrents des changements prsents 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 problme ct humain, technique ou mme financier peut causer un retard sur les dlais fixs et ainsi forcer le chef de projet justifier son retard auprs du client, pouvant aller jusqu un geste commercial de la part de la socit en charge du projet.
Page 13 / 79
Audrey LEPICOUCHE
2007
4.1.3.4
Les changements dans le management financier
Les changements dans le management financier sont nombreux et surtout diversifis. Les changements qui seront tudis dans ce mmoire seront les changements tels que les restrictions budgtaires ne permettant plus, par exemple, dutiliser 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 comptence, voire un changement des besoins client pour lesquels lquipe en charge du projet na pas les comptences. Il peut aussi y avoir, mais plus rarement, des changements tels que le rachat de la socit, 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 problme dans la gestion du projet. En effet, les changements qui seront abords dans ce mmoire sont des changements comme le produit final qui est non fonctionnel dans lenvironnement client. Un changement de matriel chez le client qui peut, dans le cas dun projet de supervision et dexploitation dun rseau, empcher le bon fonctionnement de la supervision et par consquence provoquer une mauvaise exploitation. Dans ce mmoire, afin de mieux comprendre la conduite suivre si un changement intervient lors dun projet informatique, il va falloir trouver les solutions les mieux adaptes pour palier ces changements inattendus et surtout imprvisibles. Pour trouver ces solutions, il faut, dans un premier temps, faire un audit de lexistant et des solutions actuellement mises en place pour palier aux changements. Lexistant sera toff par des exemples pris sur deux types de projets, le premier projet consiste mettre en place une application permettant au client de grer et unifier la documentation utilise au sein de sa socit. Le second projet sera un projet dintgration de systme de la socit cliente dans la socit en charge du projet avec de la supervision et de lexploitation.
4.2
Audit / Diagnostic de lexistant
Comme il a t prcis dans le paragraphe prcdent, les solutions trouves au long de ce mmoire vont tre bases sur des exemples tirs de deux projets. Afin de trouver ces solutions nouvelles, il est important de faire un audit de lexistant. Cet audit va permettre de comprendre quelle conduite suive les socits lorsque des changements interviennent durant des projets de type informatique. Pour cela, il sera dtaill ci-aprs les diffrentes conduites qui ont t mises en uvre pour chacun des changements cits dans les paragraphes prcdents.
Page 14 / 79
Audrey LEPICOUCHE
2007
4.2.1 La conduite suivie lors dun changement humain

Aprs avoir effectu des recherches sur les conduites qui sont actuellement suivies lors dun changement humain durant un projet informatique, le constat est que les conduites sont trs varies. Les conduites suivies lors de changement humain vont tre exposs 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 grer le projet de bout en bout. Le chef de projet a la mission de planifier le projet, den comprendre et den recueillir les besoins, de faire des runions de pilotage avec lquipe projet mais galement avec le client Ces points sont importants car ils permettent de mieux comprendre la conduite suivre lors dun changement de chef de projet. Diffrentes actions sont actuellement menes lorsquun 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 dcrivant ces fonctions. Les recherches se font soient en interne, soient en ouverture de poste sur le march du travail, soient en faisant appel une socit de prestations. Suite aux entretiens effectus pour ce poste, le nouveau chef de projet doit rpondre plusieurs conditions dont la plus important est dtre disponible immdiatement, puis connatre les technologies utilises dans le projet en cours. Une fois, le nouveau chef de projet trouv, une runion est organise entre les deux chefs de projet, le prdcesseur et le successeur. Cette runion a pour but deffectuer un transfert de comptences sur le projet en question. Cette runion na pas pour but de faire un transfert de comptences technique mais bien un transfert de comptences sur la partie gestion de projet, savoir les besoins exprims par le client, les technologies utilises, lavancement du projet, le planning prvu, lquipe projet mis disposition Cette runion est organise le plus rapidement possible afin de librer au plus vite le chef de projet sortant. Suite ce transfert de comptences, le chef de projet sortant organise une runion interne avec lquipe projet afin de prsenter le nouveau chef de projet. Cette runion permet galement de rendre compte de lavancement du projet en laissant notamment le nouveau chef de projet prendre en main la runion de travail. Le dernier point que les chefs de projet doivent effectuer ensemble avant deffectuer le changement de poste est dorganiser une runion avec le client afin de lui prsenter son nouvel interlocuteur.
Page 15 / 79
Audrey LEPICOUCHE
2007
Cette runion se fait avec les deux interlocuteurs et comporte dans la plupart des cas deux points, le premier consiste prsenter le nouveau chef de projet et le second consiste faire une runion de pilotage afin de prsenter au client ltat davancement du projet. A la fin de cette runion 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 dautres situations qui pourraient rendre indisponible le chef de projet sortant comme dans les cas extrmes le dcs de ce dernier. Dans ce cas, la marche suivre sera lgrement diffrente. En effet, toutes les actions faites en coopration avec les deux chefs de projet nont plus lieu dtre ou doivent tre plus ou moins modifies. La premire action, celle de trouver un nouveau chef de projet, ne change pas. Une fois le remplaant trouv, la runion de transfert de comptence se fait non pas entre les deux chefs de projet mais entre le remplaant et son responsable, en compagnie dun membre de lquipe projet. Ensuite, le nouveau chef de projet est prsent lquipe par le responsable. En dernier lieu, une runion de pilotage est organise avec le client pendant laquelle le nouveau chef de projet se prsente et donne un tat davancement du projet.
4.2.1.2
Le collaborateur
Ce cas de changement concerne le changement dun collaborateur. Le terme de collaborateur dsigne un membre de lquipe projet, cest dire une personne sous la responsabilit du chef de projet. Un membre de lquipe projet est un technicien dont les comptences sont en concordance avec les technologies utilises dans le projet. Il est important de comprendre que le collaborateur ne pourra partir que lorsque son remplaant sera en place au sein de lquipe projet sauf dans le cas o le changement est d un dcs ou tout autre vnement empchant une relation entre les deux collaborateurs, le prdcesseur et le successeur. Dans ce paragraphe vont tre prsents les diffrentes actions qui sont mens lorsquun 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 prcdent, la recherche du nouveau collaborateur se fait dans un premier temps en effectuant une fiche de poste, puis en recherchant les diffrents profils soient en interne, soient sur le march du travail, soient par le biais dune socit de prestation. Une fois le nouveau collaborateur trouv, ce dernier est prsent lquipe projet. Puis un transfert de comptence est organis entre le collaborateur sortant et le remplaant. Ce transfert de comptence a un impact sur le planning du projet. En effet, il faut que le collaborateur sortant prsente au nouveau collaborateur les diffrents modules du projet qui ont t dvelopps mais galement les modules restant. Pendant cette prsentation, le dveloppement dont le collaborateur sortant est en charge navance pas.
Page 16 / 79
Audrey LEPICOUCHE
2007
Ce dernier point oblige le chef de projet refaire une planification sur lavancement du projet. Le chef de projet estime le temps de transfert de comptence puis planifie les modules de ce dernier en fonction du temps pass sur le transfert de comptence. Si le temps de transfert de comptence estim est de deux jours, le projet est galement dcal de deux jours. Si le temps de transfert de comptence met en pril les dlais de ralisation annoncs au client, le chef de projet fait une planification mettant en vidence le retard. Par la suite, le chef de projet organise une runion de pilotage avec le client afin de lui prsenter les diffrents changements, savoir ltat davancement du projet, comme les modules dvelopps par les collaborateurs non changeant , puis la replanification des modules du nouveau collaborateur impliquant donc une replanification du projet. Comme il a t prcis dans lintroduction de ce paragraphe, le changement de collaborateur peut tre d au dcs ou tout autre vnement empchant un transfert de comptence entre les deux collaborateurs. Dans ce cas, le transfert de comptence sera fait par le chef de projet en lui prsentant le projet et les modules restants.
4.2.1.3
Les arrts maladie
Les arrts maladies sont des vnements imprvisibles quelque soit le domaine ou le mtier dans lesquels ils apparaissent. Dans le cas dun projet informatique, ce type de changement se gre de trois manires diffrentes, selon des courtes, moyennes ou longues dures. Les courtes dures sont dfinies comme allant de un deux jours maximum. Les arrts de moyenne dure nexcdent pas une semaine, cest dire cinq jours ouvrs. Les arrts de longue dure sont des arrts dpassant cinq jours ouvrs. Selon les dures darrts maladie qui sont dposs par les collaborateurs, les conduites suivre sont diffrentes et cest ce qui va tre dcrit dans ce paragraphe. Dans le cas dun arrt de courte dure, le chef fait un changement sur le planning du projet. Il dcale la dure du projet et plus prcisment du module dont le collaborateur malade est en charge de la dure de larrt maladie. Par exemple, si larrt maladie est de deux jours, le chef de projet allonge de deux jours le module et dcale ainsi toutes les phases du projet dpendantes du module. Dans le cas dun arrt de moyenne dure, et afin de ne pas mettre en pril les dlais du projet, le chef de projet dcide de faire une distribution du travail en cours du collaborateur malade. Il distribue ainsi les tches de ce collaborateur vers les autres collaborateurs, seulement si le travail en cours a des consquences sur les dlais sil nest pas effectu en temps et en heure. Dans le cas dun arrt maladie de longue dure, le chef de projet dcide de prendre un nouveau collaborateur dans lquipe en attendant le retour du collaborateur titulaire . Dans ce cas, il faut se rfrer au paragraphe prcdent dans lequel il est expliqu la conduite suivre lorsquil y a un changement de collaborateur. Dans le cas o larrt maladie concerne le chef de projet, les actions prises sont sensiblement les mmes. La conduite de changement de management de projets informatique Page 17 / 79
Audrey LEPICOUCHE
2007
Lorsquil sagit dun arrt maladie de courte dure, il ny a pas de remplacement de prvu, sachant quun arrt de courte dure dure au maximum deux jours, il nest pas ncessaire de prvoir de remplaant. Dans le cas o durant ces deux jours il y a un souci majeur sur le projet, cest le responsable du chef de projet qui gre les soucis. Il en va de mme pour les arrts de moyenne dure. En effet, le projet est alors dirig par le responsable du chef de projet ou par un supplant, membre de lquipe projet, dsign soit par le chef de projet, soit par son responsable. Dans le cas dun arrt de longue dure, le responsable du chef de projet fait une recherche dun remplaant. Pour cette dmarche, il faut se reporter au paragraphe intitul Chef de projet dans lequel est explique la dmarche suivre lors dun changement inattendu de chef de projet.
4.2.1.4
Les congs pays
Contrairement aux arrts maladie, les congs pays sont des vnements prvisibles plus ou moins long terme. Il convient, par la suite au chef de projet, de planifier les congs pays de ces collaborateur afin de faire une planification correcte du projet ds son commencement. Pour cela, plusieurs conduites sont suivre selon que le projet est un projet longue dure ou courte dure. Il est entendu par projet longue dure , un projet dont la planification dpasse six mois. Dans ce cas prcis, le chef de projet est en charge de demander tous ces collaborateurs de poser leurs congs au dbut du projet afin que le chef de projet puisse planifier les diffrentes phases du projet en fonction des congs de chacun de ces collaborateurs. Si la planification du projet passe sur lanne suivante, le chef de projet demande alors ces collaborateurs de lui donner les futurs congs que ces derniers souhaitent poser. En ce qui concerne les projets dit de courte dure , les collaborateurs doivent poser leurs congs pour la priode 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 dun changement technique

Dans cette partie, laudit va sappuyer sur des exemples bass sur les deux projets cits en conclusion du paragraphe sur lenvironnement (4.1). Pour rappel, les deux projets utiliss comme exemple sont, pour le premier, le dveloppement dune application permettant de grer et dunifier la documentation au sein dune socit, pour le second projet, il sagit dintgrer les quipements du rseau client sur les consoles de supervision afin den assurer la surveillance et lexploitation. Les changements techniques durant un projet informatique peuvent tre nombreux et trs varis. Dans ce paragraphe, les diffrentes conduites suivre, suivant le changement, vont tre exposes. Les changements tudis seront au nombre de trois.
Page 18 / 79
Audrey LEPICOUCHE
2007
4.2.2.1
Langage de programmation
Les langages de programmation sont des spcialits dans linformatique. Il y a en effet des techniciens spcialiss dans un type de langage. Dans ce paragraphe, il est dtaill 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 lexemple de lapplication de gestion de documentation, au commencement du projet le client souhait un logiciel installer sur chaque poste, par la suite il dcide que lapplication sera une application de type web accessible par chaque employ partir de lintranet. Cela implique bien entendu un changement de langage de programmation, car une application web ne se dveloppe pas dans le mme langage quun 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 dj effectu et plus particulirement du temps dj consacr sur le projet depuis son commencement. Suite cette analyse, le chef de projet organise une runion de travail avec lquipe projet afin de connatre les enjeux et surtout les consquences dun tel changement. Suite aux indications que donneront chacun des collaborateurs sur les consquences dun tel changement, le chef de projet va estimer les consquences au niveau financier afin de pouvoir ngocier avec le client, il va refaire une planification en incluant les changements. Il va monter un dossier prsenter ses responsables mais surtout au client afin de montrer les consquences dun tel changement. En parallle, il va faire un tat des comptences prsentes dans son quipe projet sur le nouveau langage de programmation. Cet tat sera fait durant la runion de travail. En fonction de cet tat, si tous les collaborateurs sont comptents dans le nouveau langage de programmation alors aucune action nest prvoir. Par contre si seulement une partie des collaborateurs a les comptences et lautre 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 coter ces formations et mettre jour le planning du projet en tenant compte de ces formations. Dans le cas o des collaborateurs nont aucune notion sur le langage de programmation demand, le chef de projet doit alors faire des recherches pour des nouveaux collaborateurs. La dmarche suivre est celle prsente 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 dpart zro du projet avec le recueil des besoins, la recherche de collaborateurs si ncessaire. Aprs toute cette analyse, le chef de projet organise une runion de pilotage avec le client afin de lui prsenter le dossier montrant les consquences dun changement de langage sur le projet, les cots financiers que cela implique, ainsi que le dlai supplmentaire que cela va prendre.
Page 19 / 79
Audrey LEPICOUCHE
2007
4.2.2.2
Architecture rseaux
Larchitecture rseau est au cur des toutes entreprises. Elle est souvent complexe et demande beaucoup de travail. Beaucoup de socit veulent se dcharger de cette tche fastidieuse qui est lexploitation du rseau de leur socit. Pour cela ils font appel des socits spcialises dans la supervision et lexploitation des systmes et rseaux. Ceci fait donc rfrence au second projet qui est utilis comme exemple dans ce mmoire. Dans ce paragraphe est dtaille la conduite suivre lorsquun changement sur larchitecture rseau intervient durant un projet. Il peut y avoir des changements de ce type dans deux cas, soit un changement ct chef de projet, soit un changement ct client. Si le changement est ct chef de projet, ce dernier fait partie dune socit qui elle aussi une architecture rseau qui peut tre amene 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 effectus et les impactes techniques que cela peut avoir sur le projet en cours. Pour monter le dossier, le chef de projet organise une runion de travail afin de voir avec ces collaborateurs quelles sont les consquences que cela peut entraner pour le client. Dans ce cas prcis, cela naura pas dimpact financier pour le client car il ne sagit pas de son architecture, par contre cela peut avoir des consquences techniques comme lajout dadresses de routage dans son plan dadressage interne. Il peut galement y avoir des changements au niveau des dlais de ralisation du projet. Une fois le dossier mont, le chef de projet organise une runion de pilotage avec le client afin de lui prsenter le changement et les consquences qui en dcoulent. Si le changement est ct client, cela a galement des impacts sur le projet en cours. Pour cela, le chef de projet organise une runion de pilotage avec le client afin de connatre les impacts techniques de ce changement. Suite cette runion, le chef de projet organise une runion de travail avec lquipe projet afin de prsenter les changements darchitecture 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 prsenter les changements que les changements darchitecture cliente impliquent, les cots financier prvoir et refait une planification en fonction de ces informations. Il organise par la suite une autre runion avec le client afin de lui prsenter le dossier et les solutions trouves.
4.2.2.3
Systme dexploitation
Les systmes dexploitation sont comme larchitecture rseau, un point essentiel de linformatique dans une socit. Ds que des modifications sont faites sur un de ces deux lments fondamentaux cela peut avoir des impacts ngatifs sur une socit.
Page 20 / 79
Audrey LEPICOUCHE
2007
Un changement de systme dexploitation peut avoir un impact sur le dveloppement dun logiciel. Pour illustr ce paragraphe, lexemple de lapplication permettant de grer la documentation dune socit sera utilis. En effet dans le cas o cette application est un logiciel, il faut sassurer que ce dernier soit utilisable et/ou reconnu sous un nouveau systme dexploitation. Dans ce paragraphe est dtaille la conduite suivre lorsquun changement de systme dexploitation intervient durant un projet. Dans un premier temps, le chef de projet organise une runion de travail avec ces collaborateurs afin de faire un tat des comptences de chacun sur le systme dexploitation que le client met en place. En fonction de cet tat, si tous les collaborateurs sont comptents dans le nouveau systme dexploitation alors aucune action nest prvoir. Par contre si seulement une partie des collaborateurs a les comptences et lautre 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 coter 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 matriel ncessaire ainsi que le systme dexploitation utilis par le client afin que ces collaborateurs puissent dvelopper le projet sur le bon environnement. Le chef de projet doit pour cela faire un devis pour le matriel. Par la suite, le chef de projet monte un dossier rcapitulant les impacts quun tel changement a sur le projet, comme les impacts financiers (achat de matriel, formations ), les impacts techniques et les solutions apportes, les impacts concernant les dlais.
4.2.3 La conduite suivie lors dun changement commercial

Le domaine commercial est un domaine trs important dans une socit, sans ce domaine il ny a pas de contrat ngoci et/ou dcroch, soit pas de projets traiter. Lorsquun changement de type commercial survient durant un projet informatique cela peut entraner des vnements pouvant perturber le bon droulement du projet comme les retards sur les dlais, ou les changements sur des aspects techniques Dans ce paragraphe, il sera dtaill quelles sont les conduites qui sont actuellement suivies lorsque de tels changements surviennent, comme des changements de primtre ou des avenants au contrat.
4.2.3.1
Modification de primtre
Le domaine commercial est un domaine important durant la phase projet. En effet, le commercial est, avec le chef de projet, un point dentre 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.
Page 21 / 79
Audrey LEPICOUCHE
2007
Lorsque le client dcide de modifier le primtre qui a t dfini lors de la signature du contrat, il en avise le commercial afin dtablir les lments ncessaires pour que le changement de primtre soit pris en compte dans le contrat. Le commercial doit alors prvenir le chef de projet quun changement de primtre a t sign avec le client et quil faut le prendre en compte. Le commercial doit galement fournir au chef de projet le nouveau primtre afin que ce dernier puisse faire un point sur les nouveauts et/ou les changements apports au contrat. Une fois que les informations de changement de primtre sont parvenues jusquau chef de projet, ce dernier doit dans un premier temps faire un tat des modifications qui dcoulent du changement de primtre. Dans un second temps, il doit tablir une estimation de la charge de travail quapporte ce changement de primtre. Une fois cette estimation faite, le chef de projet doit faire une planification et voir si ce changement de primtre apporte des modifications dans les dlais comme du retard ou de lavance. Si le changement de primtre implique un retard sur les dlais prvus pour le projet, le chef de projet doit alors en informer le client en lui demandant une runion de pilotage de projet dont lordre du jour concernera le changement de primtre. Lors de cette runion de pilotage, le chef de projet doit, premirement, valider le nouveau primtre avec le chef de projet et deuximement annoncer au client les nouveaux dlais qui ont t calculs en fonction du changement de primtre. Une fois cette runion termine, le chef de projet doit organiser une runion de travail avec ces collaborateurs afin de les prvenir du changement de primtre mais galement des nouvelles tches quils aient effectuer pour prendre en compte ce nouveau primtre.
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 primtre, ou la suite doffre commerciales faites par le commercial afin de proposer au client dautres services, comme proposer de la maintenance ou de linfogrance en fonction des projets. Les conduites suivre lorsquil y a des avenants au contrat qui sont signs sont sensiblement identiques la conduite suivie lors dun changement de primtre. La diffrence entre ce paragraphe et le prcdent est la chronologie des vnements. En effet dans le paragraphe prcdent, lors du changement de primtre, les actions se situaient pendant le droulement du projet. Dans le cas de ce paragraphe, les avenants au contrat sont signs une fois que le projet est termin. Le commercial annonce alors au chef de projet quun avenant au contrat a t tabli et il demande ce que cet avenant soit trait en mode projet . Par consquent, un chef de projet est nomm, soit la personne qui t en charge du projet initialement, soit une nouvelle personne.
Page 22 / 79
Audrey LEPICOUCHE
2007
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 comptences requises pour le projet. Dans un second temps, le chef de projet planifie le projet en fonction de la charge de travail et des diffrents congs pays dposs par les membres de lquipe projet la demande du chef de projet. Par la suite, et en parallle du droulement du projet, le chef de projet doit tablir la documentation ncessaire la gestion de projet, organiser des runions 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 dun changement financier

Le domaine financier est un domaine qui touche tous les mtiers. Dans les projets informatiques, le domaine financier permet tout simplement de les faire exister et perdurer. Lorsquun changement de type financier survient durant un projet informatique cela peut entraner dans des cas extrmes labandon de ce dernier. Dans ce paragraphe, il sera dtaill 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 budgtaires
Les restrictions budgtaires sont des changements qui sont amens par les responsables des socits et pour lesquels le chef de projet na aucun contrle. Ds quil y a des restrictions budgtaires, le chef de projet est en charge de trouver les moyens de rduire les cots pour ces projets en cours. Ces rductions peuvent aussi bien se faire au niveau matriel quau niveau personnel. Comment un chef de projet gre donc ce type de changement lorsquil survient durant un projet informatique ? Dans un premier temps, il fait une analyse des diffrentes parties de son projet, comme lquipe projet, lavancement du projet, les dpenses quil reste faire A partir de cette analyse, le chef de projet doit mettre en place des actions permettant de rduire les dpenses. Dans lexemple du dveloppement dune application, lquipe projet doit dvelopper diffrents modules qui une fois rassembl forme lapplication dfinitive. Avec cette situation de restrictions budgtaires, le chef de projet dcide que les dveloppeurs ayant termin leur module sont remerci et mis en attente dun nouveau projet, ceci permet donc de faire des conomies au niveau des charges du personnel avec entre autres des personnes en moins pour lquipe 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 nest pas forcment dvoil au client). Donc si le commercial a prvu dix personnes pour le projet et quil ny en a plus que sept maintenant, cela fait donc faire des conomies de budget au chef de projet.
Page 23 / 79
Audrey LEPICOUCHE
2007
Dans un second temps, le chef de projet peut organiser une runion de pilotage avec le client afin de lui faire des propositions damliorations sur le projet. Afin de prparer cette runion, le chef de projet doit au pralable organiser une runion de travail avec ces collaborateurs afin de trouver des solutions moins coteuses pour le projet. A la suite de cette runion, le chef de projet monte un dossier, quil prsentera au client lors de la runion de pilotage. Ces modifications vont surtout porter sur le changement de spcifications fonctionnelles, cest dire, non pas la manire dont va tre dvelopp lapplication qui sont des spcifications techniques, mais plutt la manire dont lapplication fonctionnera dun point de vue utilisateur final. En effet, moins de pages sont dveloppes moins lapplication cote en terme de temps et de ressources. Cela entrane ainsi des conomies budgtaires.
4.2.4.2
Dpenses imprvues
Les dpenses imprvues dcoulent la plupart du temps des changements qui interviennent dans les autres domaines, comme les changements de type humain, financier, technique En effet, lorsquil y a un changement de collaborateur ou de chef de projet, cela cote financirement la socit, puisquil faut entreprendre des recherches, faire passer de entretiens, faire des transferts de comptences Pour cela, il faut du temps et des ressources, autrement dit de largent. Selon les changements, ces derniers peuvent tre causs soient par le client, comme les changements techniques, soient par lquipe projet comme les changements humains. Dans tous les cas, le chef de projet doit faire une analyse des dpenses engendres par ces changements afin de trouver des solutions pour viter ces changements. Les solutions ne peuvent pas toujours viter les dpenses, dans ce cas il est important que le chef de projet trouve la solution la moins coteuse ou du moins la plus rentable. Si, par exemple, il y a un changement technique, deux solutions sont possibles. La premire solution est dorganiser 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 coteuse, mais la plus rentable. Si cest dpenses sont invitables, le chef de projet doit monter un dossier prsentant tous les arguments ncessaires afin dobtenir le budget pour assurer ces dpenses imprvues.
4.2.4.3
Rorganisation ou rachat de la socit
Le changement qui va tre prsent est un changement trs rare, il sagit dun rachat ou dune rorganisation de la socit (cliente ou non). Dans le cas o la socit qui est rachet ou qui subit une rorganisation est la socit cliente, cela amne dans la majeure partie des cas labandon du projet. Dans lautre cas, savoir la socit subissant le changement est la socit qui est en charge du projet, est un cas bien souvent plus favorable au maintient du projet car pour la socit qui achte, cela fait un client et une rentre dargent en plus. Dans ce paragraphe, il sera dtaill dans les deux cas, les conduites suivre lors de tels changements. La conduite de changement de management de projets informatique Page 24 / 79
Audrey LEPICOUCHE
2007
Le premier cas est celui de la socit cliente qui subit le changement mais dont le projet quelle a demand raliser est maintenu. Dans ce cas, le chef de projet doit imprativement et dans des dlais trs courts, organiser une runion avec le client afin de connatre les consquences dun tel changement, savoir en particulier sil y aura des modifications au niveau des besoins, si linterlocuteur ct client sera toujours le mme De plus, lors de cette runion, le chef de projet doit sattendre tre mis en contact avec de nouvelles personnes de la socit cliente o il sera certainement amen prsenter lavancement du projet. Il faut bien entendu que le chef de projet ait prpar sa runion en effectuant au pralable une runion de travail avec ces collaborateurs afin de se tenir inform de lavancement du projet. Le second cas est celui o la socit en charge du projet client est rachete ou subit une rorganisation et que bien entendu, le projet est maintenu. Le rachat ou la rorganisation de socit entrane bien souvent des changements humains ce qui peut troubler lavancement dun 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 runion avec son responsable afin de se renseigner sur les consquences 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 sattendre 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 prparer un dossier de prsentation du projet pour sa direction, dans le cas o cette dernire souhaiterait avoir des informations sur ce projet. Ce dossier doit comporter tous les lments ncessaires au projet, en allant du cahier des charges, en passant par la composition de lquipe projet, le planning, les comptes rendus de runion . Une fois que le chef de projet toutes les informations ncessaires concernant le projet et son avancement, le chef de projet doit organiser une runion de pilotage avec le client afin dans un premier temps de le rassurer sur le devenir de son projet, puis afin de lui prsenter les ventuels changements concernant le projet, comme le changement de chef de projet par exemple. En parallle, avant ou aprs la runion cliente, le chef de projet doit galement organiser une runion interne avec ses collaborateurs afin de les prvenir des changements ventuels d au changement de direction.
4.2.5 La conduite suivie lors dun changement en production

La production est la partie ultime dun 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 mme des actions faire afin de sassurer 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 prsents avec le dtail des conduites suivre pour chacun des changements.
Page 25 / 79
Audrey LEPICOUCHE
2007
4.2.5.1
Produit final non fonctionnel
Le premier changement, durant la production, qui est prsent dans ce mmoire concerne le produit final et plus particulirement le fait que ce dernier soit non fonctionnel dans lenvironnement client. Dun point de vue client, le produit final tant non fonctionnement cela implique que le chef de projet na pas abouti aux rsultats souhaits. 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 ct de lquipe 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 laide des collaborateurs du chef de projet avec lorganisation dune runion dite ici de crise . A la suite de lanalyse faite par le chef de projet, il convient que se dernier organise une runion avec le client afin de comprendre avec lui se qui a pu se passer pour que le produit final ne soit pas fonctionnel dans lenvironnement client. Le chef de projet devra durant cette runion, demander au client ci ce dernier na pas effectu des changements, quels quils soient, dans son environnement. Si cest le cas, le chef de projet devra faire une liste des changements que le client a effectus. Une fois cette liste tablie, le chef de projet doit organiser une runion de travail avec ces collaborateurs afin de trouver ensemble des solutions pour que le produit final devienne fonctionnel dans lenvironnement client.
4.2.5.2
Architecture cliente modifie
Une architecture cliente modifie peut tre lie au changement vu prcdemment, ainsi avec un changement dans larchitecture cliente le produit final peut ne plus tre fonctionnel dans lenvironnement client. Il est appel architecture cliente modifie , tout changement au niveau rseau, systme dexploitation amenant ainsi un impact sur larchitecture actuelle, cela implique des changements trs importants dans une socit et pouvant amener des consquences ngatives sur la production. Dans ce paragraphe, contrairement au prcdent, le projet est en phase final, mais cela nest pas le jour de mise en production. Le client prvient le chef de projet dun changement dans larchitecture quelques jours avant la date fixe pour la mise en production. Dans un premier temps, le chef de projet doit avertir ces collaborateurs afin que ces derniers arrtent les derniers ajustements en cours sur le projet. Dans un second temps, le chef de projet doit organiser de manire rapide une runion avec le client afin que ce dernier lui fournisse une liste des changements qui ont ou qui vont tre effectus dans larchitecture cliente. Le chef de projet, avec la liste fourni par le client, doit faire de son ct une liste des impacts que ces changements vont avoir sur la mise en production du projet dans lenvironnement client. Suite cette liste, il doit organiser une runion interne avec ces collaborateurs afin que le chef de projet puisse avec leur collaboration dterminer la charge de travail restante. La conduite de changement de management de projets informatique Page 26 / 79
Audrey LEPICOUCHE
2007
Le chef de projet doit plus particulirement effectuer une tude de faisabilit suite aux impacts que ce changement a sur le projet. Suite cette tude, si la faisabilit est vrifie, le chef de projet doit faire une planification pour effectuer les changements sur le projet en fonction des changements effectus sur larchitecture cliente. En dernier lieu, il faut que le chef de projet convienne avec le client dune nouvelle date de mise en production du projet.
4.3
Critique de lexistant
Cette partie consiste mettre en vidence les aspects ngatifs de laudit fait dans le paragraphe prcdent. De cette critique, nous pourrons, par la suite, mieux cerner les conduites qui ne permettent pas aux chefs de projet de faire face de manire positive aux changements. Nous pourrons alors dans un des chapitres suivants donner des solutions pouvant mieux rpondre aux attentes de ces chefs de projet face aux changements.
4.3.1 La conduite suivie lors dun changement humain

Aprs avoir dtaills dans les paragraphes prcdents, les diffrentes conduites qui sont suivies lors de changements inattendus durant un projet informatique, il sera dtaill dans ce paragraphe les critiques qui peuvent tre faites sur ces conduites et plus particulirement sur les changements survenant dans le domaine de lhumain. Comme il a t prcis prcdemment, les quatre changements au niveau humain qui sont tudis sont les changements de chef de projet ou de collaborateur et les conduites suivies lors de dpart en congs pays ou en congs maladies.
4.3.1.1
Chef de projet
Les critiques qui peuvent tre faites sur les conduites suivies lors dun changement de chef de projet ne sont pas nombreuses mais ces critiques peuvent amener trouver des solutions afin que les changements inattendus nait pas deffets ngatif sur le bon droulement des projets. La premire critique qui est souleve concerne la transparence des faits vis vis du client mais galement vis vis des membres de lquipe projet. En effet, les responsables du chef de projet nont pas fait de bilan sur le dpart du chef de projet, ils nont pas list les raisons de son dpart. Si le client ou un membre de l quipe projet pose des questions sur le dpart du chef de projet, les responsables pourront se retrouver dpass par la question montrant ainsi une faiblesse. Cette dernire pourra alors tre interprte par les diffrents acteurs comme une angoisse et ainsi provoquer des incertitudes et des interrogations au sein de lquipe projet mais galement vis vis du client. Laisser des personnes avec des sentiments dincertitudes et dinterrogations peut avoir des consquences ngatives sur un projet. La conduite de changement de management de projets informatique Page 27 / 79
Audrey LEPICOUCHE
2007
La seconde critique qui est souleve 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 diffrentes informations qui ont circules sur le projet. En effet, sans ces informations le transfert de comptences ou dinformations prend plus de temps. De plus, il est vident que toutes les informations ne seront pas communiques au nouveau chef de projet car lHomme na pas la capacit de retenir 100% les informations qui lui ont t transmises durant le projet, il y a ainsi une perte dinformation entre le prdcesseur et le successeur. Cette critique est dautant plus valable dans le cas o le dpart du chef de projet serait d, dans le cas extrme, au dcs de celui-ci. Dans ce cas, il ny a pas de transfert dinformations entre le prdcesseur et le successeur entranant ainsi une perte de connaissance sur le projet mais aussi une perte de temps.
4.3.1.2
Collaborateur
Les critiques souleves dans ce paragraphe sont faites sur les conduites qui sont suivies lorsquun changement de collaborateur intervient durant un projet informatique. Les conduites dtailles dans les paragraphes prcdents montrent des faiblesses mettre en avant afin dviter toutes consquences ngatives sur les projets. La premire critique est porte essentiellement sur le chef de projet et la gestion de son quipe. En effet, lerreur est de ne pas avoir prvu initialement une quipe projet avec un nombre de personnes plus important. Pour tre plus prcise, si un collaborateur dcide de partir, il faut lui trouver un remplaant, le former et attendre quil soit oprationnel pour que le projet continu. Le chef de projet doit initialement prvoir dans ces effectifs des collaborateurs remplaants qui seront oprationnels plus rapidement vitant ainsi une perte de temps et ainsi un dpassement de dlais. La seconde critique porte galement sur la gestion du projet faite par le chef de projet. En effet, la faille dcele dans la conduite dtaille prcdemment concerne le planning du projet. Le chef de projet aurait d prvoir dans la planification de son projet une charge ventuelle de problmes humains, tout ceci afin dviter des pertes de temps impliquant des retards dans les dlais donns au client.
4.3.1.3
Les arrts maladie
Les critiques portes dans ce paragraphe concernent la gestion des arrts maladie. En effet sur la conduite dtaille dans le paragraphe sur lanalyse de lexistant, il est mis en vidence certaines faiblesses. La critique qui peut tre faite est la mme que celle faite sur les changements de collaborateurs. Lerreur du chef de projet est de ne pas avoir prvu initialement une quipe projet avec un nombre de personnes plus important. Pour tre plus prcise, si un collaborateur tombe malade dans le cas dun arrt maladie de longue dure, il faut lui trouver un remplaant, le former et attendre quil soit oprationnel pour que le projet continu. La conduite de changement de management de projets informatique Page 28 / 79
Audrey LEPICOUCHE
2007
Le chef de projet doit initialement prvoir dans ces effectifs des collaborateurs remplaants qui seront oprationnels plus rapidement vitant ainsi une perte de temps et ainsi un dpassement de dlais.
4.3.1.4
Les congs pays
Le minimum de congs pays attribu chacun des employs dune entreprise est connu de tous, il est de cinq semaines par homme et par an. Dans ce mmoire, il nest pas tenu compte des jours autres que ces cinq semaines. La critique faire sur la conduite qui a t dcrite auparavant est que le chef de projet na pas tenu compte initialement dans sa planification du nombre total en jour homme qui seront pris pour des congs pays. Sachant que nous avons 5 semaines minimum et obligatoires de congs pays par homme et par an. Il est facile de planifier en fonction de ces donnes. Cette non prise en compte des congs pays dans le planning dun projet peut mettre ce dernier en pril au niveau des dlais de ralisation annoncs.
4.3.2 La conduite suivie lors dun changement technique

Aprs avoir dtaills dans lanalyse de lexistant, les diffrentes conduites qui sont suivies lors de changements inattendus durant un projet informatique, il sera dtaill dans ce paragraphe les critiques qui peuvent tre faites sur ces conduites et plus particulirement sur les changements survenant dans le domaine technique. Comme il a t prcis prcdemment, les trois changements au niveau technique qui sont tudis sont les changements de langage de programmation, les changements darchitecture rseau et les changements de systme dexploitation.
4.3.2.1
Changement de langage de programmation
Le changement de langage de programmation, comme il a t vu dans lanalyse de lexistant, amne 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 dtaille dans ce mmoire lors de ce type de changement montre des failles qui vont tre mises en avant dans ce paragraphe. La premire faille concerne lanalyse du travail demand par le chef de projet lors de lannonce du changement de langage de programmation. En effet, la critique se porte sur le fait que cette analyse devrait se faire au fil de lavancement du projet, de manire rgulire entre le chef de projet et ses collaborateurs, tout ceci afin dviter une perte de temps lors de demandes ou lors de changements inattendus, ou afin de permettre galement de rpondre immdiatement aux questions des clients lors de runion. La seconde critique concerne le chef de projet. En effet, ce dernier aurait d faire ltat des comptences des collaborateurs initialement, avant le commencement du projet. La conduite de changement de management de projets informatique Page 29 / 79
Audrey LEPICOUCHE
2007
Ainsi cela vite au chef de projet de perdre du temps faire ltat des comptences de ces collaborateurs au moment o le changement intervient. Le chef de projet doit connatre parfaitement ses collaborateurs et surtout en terme de comptences. La dernire critique, mais non la moindre, qui peut tre faite sur la conduite suivie lors dun changement de langage de programmation durant un projet informatique concerne la slection des membres de lquipe projet. En effet, le chef de projet aurait d lors de la constitution de son quipe, sentourer de personnes multi comptentes la place de personne mono comptentes. Ainsi lors dun tel changement, les membres de lquipe projet nont pas forcment besoin dtre remplacs sils sont comptents sur le nouveau langage de programmation.
4.3.2.2
Changement darchitecture rseau
Comme il a t dtaill dans lanalyse de lexistant, les changements darchitecture rseau peuvent se faire du ct client ou du ct de lquipe projet. Dans ce paragraphe, la critique sera faite sur les changements darchitecture ct quipe projet . En effet, les changements darchitecture rseau sont des changements prvisibles puisquils demandent de nombreux prparatifs avant de pouvoir tre effectus afin dviter toutes consquences nuisibles la socit et plus particulirement 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 dlais annoncs au client.
4.3.2.3
Changement de systme dexploitation
Comme il a t expliqu dans lanalyse de lexistant, les systmes dexploitation sont comme larchitecture rseau, un point essentiel de linformatique dans une socit. Ds que des modifications sont faites sur un de ces deux lments fondamentaux cela peut avoir des impacts ngatifs sur une socit. Lors dun tel changement, le paragraphe sur lanalyse de lexistant a montr quelle conduite est aujourdhui suivie pour faire face un changement de systme dexploitation durant le projet. Mais cette conduite prsente des points faibles qui peuvent conduire une mauvaise gestion du projet et ainsi engendrer des consquences nfastes laboutissement du projet. La premire critique faire concerne le chef de projet. En effet ce dernier aurait d faire ltat des comptences de ces collaborateurs lors de la slection de ces derniers avant le commencement du projet. Cette critique a dj tait faite lors du paragraphe concernant la critique du changement de langage de programmation. La seconde critique se porte sur le choix stratgique faite par le chef de projet. En effet, il aurait t judicieux de faire une application fonctionnant avec tous les types denvironnement existant. Dans le cas o le changement de systme ne serait pas intervenu durant le projet, il est possible que le client dcide de changer de systme quelques annes plus tard impliquant dans ce cas que lapplication ne fonctionnera plus ce moment l puisquelle nest fonctionnelle quavec un seul type de systme dexploitation.
Page 30 / 79
Audrey LEPICOUCHE
2007
4.3.3 La conduite suivie lors dun changement commercial

Comme il a t expliqu dans lanalyse de lexistant, le domaine commercial est un domaine trs important dans une socit, sans ce domaine il ny a pas de contrat ngoci et/ou dcroch, soit pas de projets traiter. Le domaine commercial est trs important durant la phase projet. En effet, le commercial est, avec le chef de projet, un point dentre 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 dtailles les diffrentes critiques qui peuvent tre faites sur les conduites suivies lors de changements commerciaux intervenant durant des projets informatiques.
4.3.3.1
Comme il a t expliqu dans lanalyse de lexistant, lorsque le client dcide de modifier le primtre qui a t dfini lors de la signature du contrat, il en avise le commercial afin dtablir les lments ncessaires pour que le changement de primtre soit pris en compte dans le contrat. Pour rappel, dans ce paragraphe, la modification du primtre se fait durant le projet initial. La critique qui peut tre faite sur la conduite suivie suite lannonce par le client dune modification de primtre se porte sur les actions du commercial. En effet, le client se rapproche du commercial afin de faire sa demande de modification de primtre. La critique se porte donc sur le fait que le commercial na pas ngoci une modification des dlais du projet. Dans le cas prsent, les modifications doivent tre faites dans les dlais initialement prvus au contrat ce qui provoquer un retard sur les dlais et donc des pnalits payer au client.
4.3.3.2
Avenants au contrat
Comme il a t expliqu dans lanalyse de lexistant, les avenants au contrat sont des documents officiels permettant de mettre jour le contrat sign initialement entre les deux parties. Il a galement t dtaill prcdemment, la conduite suivie lors dun tel changement, autrement dit lors de la signature dun avenant. Cette conduite prsente nanmoins des points ngatifs 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 prsentent, soit le chef de projet ayant travaill initialement sur le projet est nomm, soit un nouveau chef de projet est nomm en labsence de lancien chef de projet. Dans le cas o le chef de projet reste le mme, la critique est que ce dernier na 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 ncessaires. De plus, le chef peut galement faire appel aux collaborateurs qui avaient travaill sur le projet initialement. La conduite de changement de management de projets informatique Page 31 / 79
Audrey LEPICOUCHE
2007
Ainsi, cela lui permet de faire un gain de temps considrable sur la rdaction de la documentation mais galement la comprhension du contexte du projet. Dans le cas o il y a un changement de chef de projet, les critiques cites prcdemment 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 runion de travail avec lancien chef de projet ci ce dernier est toujours prsent, soit en simprgnant des documentations qui ont t faites durant le projet initial. Dans un second temps, une critique est faire au commercial. En effet, le client dcide de faire une modification sur le contrat sign initialement. Lors de cette annonce, le commercial doit prparer les papiers pour lavenant mais cette action fait galement lobjet dune nouvelle facturation. Lorsque les papiers sont prts, le commercial organise une runion avec le client afin de lui prsenter le devis et les papiers signer. Lerreur du commercial dans ce cas l, est de ne pas avoir invit le chef de projet en charge des modifications participer cette runion. 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 dun changement financier

Dans ce paragraphe seront dtailles les diffrentes critiques qui peuvent tre faites sur les conduites suivies lors de changements financiers intervenant durant des projets informatiques. Dans les projets informatiques, lorsquun changement de type financier survient cela peut entraner dans des cas extrmes labandon de ces projets.
4.3.4.1
Lors de lanalyse de lexistant, il a t expliqu que le chef de projet na aucun contrle sur les restrictions budgtaires imprvues, par contre cest lui qui est en charge, par tous les moyens, de rduire les cots afin que le projet puisse continuer sans quil y ait de consquences sur son droulement. Suite ces informations et la conduite suivie face ce type de changement, deux points faibles en ressortent. La premire critique concerne le budget. En effet afin de palier ce type de changement, le chef de projet ne doit pas dpenser tout le budget attribu au projet ds le commencement de ce dernier. Cela conduit se retrouver sans financement en cas de coup dur comme par exemple lachat de nouveau matriel car il y a un changement de systme dexploitation La seconde critique qui peut tre faite la conduite suivie face une restriction budgtaire 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 coteuses que des technologies rcentes et par consquence plus coteuses et moins fiables. Cela permet ainsi de faire des conomies de budget afin de palier dventuels changements financiers durant le projet.
Page 32 / 79
Audrey LEPICOUCHE
2007
4.3.4.2
Dpenses imprvues
Dans ce paragraphe va tre expliqu le point faible de la dmarche suivie lors dun changement, tel que des dpenses imprvues comme des formations ou de nouvelles embauches, durant un projet informatique. En effet, la critique qui peut tre faite au chef de projet, cest de ne pas avoir tenu compte dans son budget des ventuelles dpenses imprvues. Il faut toujours prvoir des dpenses comme une nouvelle embauche si un collaborateur dcide de partir, des formations si un changement de langage de programmation survient durant le projet. Il nest, certes, pas facile dvaluer un montant concernant ces dpenses imprvues mais il est important de budgter ce type de dpenses afin de pouvoir faire face aux ventuels changements humains, technique
4.3.4.3
Rachat de la socit
Dans le cas du rachat dune socit, que se soit la socit cliente ou la socit en charge du projet, il est difficile pour le chef de projet de prvoir ce type de changement. En effet, ces changements sont trs rares et le chef de projet tout comme les responsables du projet ct client ne sont pas matre de la situation. Les critiques qui pourront tre faites ici seront celles qui ont t voques dans les paragraphes prcdents.
4.3.5 La conduite suivie lors dun changement en production

Comme il a t expliqu dans le paragraphe sur lanalyse de lexistant, la mise en production est la dernire ligne droite au bout de laquelle le projet sera boucl et clos. Cette phase est dlicate puisquelle est le rsultat dun travail long et de la mise en uvre du produit au sein de lenvironnement client. Dans le paragraphe de lanalyse de lexistant, il est dtaill quelle conduite est suivie lorsquun 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 lquipe projet constate quil y a eu des changements darchitecture cliente sans que lquipe en soit informe.
4.3.5.1
La conduite suivie, lorsque le produit final ne fonctionne pas dans lenvironnement client, qui a t dtaill dans lanalyse de lexistant, prsente de nombreux points faibles. Ces points faibles contribuent ce que les mises en production ne se passent pas comme le chef de projet laurait souhait.
Page 33 / 79
Audrey LEPICOUCHE
2007
La premire critique qui peut tre faite est donne au chef de projet qui na pas prvu de phase de test sur lenvironnement 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 lenvironnement client afin de sassurer de la bonne compatibilit entre le produit et lenvironnement client. La seconde critique est que le chef de projet nait pas propos lors de la runion dinitialisation avec le client, que lquipe projet soit dtache dans les locaux du client afin dans un premier temps de travailler au sein de lenvironnement client cartant ainsi tout incompatibilit entre le produit et lenvironnement client, puis dans un second temps davoir le contact direct avec le client et ainsi viter toute perte de temps pour les communications entre le client et lquipe charge du projet. Une autre critique relever est le fait que le chef de projet nait pas prpar la mise en production. En effet, le chef de projet aurait d, afin de prparer la mise en production, faire une runion de passage en production avec le client. Cette runion aurait permis de savoir si le client na effectu aucune modification sur son environnement et surtout de lister avec lui les pr requis ncessaires la mise en production. En dernier point, un autre point ngatif, qui peut tre tir des conduites suivies, est quil aurait fallu prvoir ou lister les diffrents checs susceptibles dapparatre durant la phase de mise en production pour pouvoir trouver les solutions et remdier ce type dvnement.
4.3.5.2
Comme il a t expliqu lors de lanalyse de lexistant, il est appel architecture cliente modifie , tout changement au niveau rseau, systme dexploitation amenant ainsi un impact sur larchitecture actuelle, cela implique des changements trs importants dans une socit et pouvant amener des consquences ngatives sur la production. Lors dun tel changement, les paragraphes prcdents ont montr quelle conduite est suivie. Cette conduite montre nanmoins des points faibles pouvant empcher la bonne conduite suivre afin de palier au changement. Les points faibles relever sont quivalent ceux voqu lors dun changement de systme dexploitation. Dans un premier cas, il aurait t judicieux de faire une application fonctionnant avec tous les types denvironnement existant. Lorsque le client annonce alors le changement, il suffit seulement de faire des paramtrages adquats afin que le produit soit fonctionnel dans lenvironnement modifi. Dans un second cas, comme dans le projet dintgration dquipements rseaux au sein de plateformes de supervision, lorsque le client annonce un changement darchitecture comme la refonte du plan dadressage IP de la socit, cela implique des changements faire au sein de larchitecture de la socit en charge du projet. Le chef de projet aurait alors d prvoir une architecture telle que lorsquun tel changement intervient, il ny a aucune modification faire du ct de lquipe projet.
Page 34 / 79
Audrey LEPICOUCHE
2007
5.
Mthodes et dmarches utilises
Les mthodes utilises pour rpondre la question fondamentale sont nombreuses. La premire consistait suivre un plan bien prcis pour le droulement du mmoire. La seconde mthode consistait effectuer des recherches documentaires sur le sujet afin de mieux comprendre lexistant mais galement afin de faciliter les recherches de solutions. Pour cela il fallait dans un premier temps sappuyer sur la documentation existante afin dexpliquer et de bien dfinir les diffrents points qui sont au cur de ce mmoire : conduite de changement, les diffrents types de management et de changement et les projets informatiques. Il fallait donc, pour obtenir des rsultats, sappuyer sur la documentation prsente sur internet mais galement sur les livres qui ont t crits sur le sujet et qui sont accessibles dans les bibliothques. Dans un second temps, une fois lexistant bien dtaill et expliqu, le travail consistait apporter les solutions aux problmes de lexistant. Autrement dit, il fallait selon les diffrents contextes, lister les diffrentes amliorations apporter lexistant, et donner les solutions ces amliorations. Il tait important ce moment du mmoire dapporter des solutions nouvelles. Pour cela, il tait bon de prendre les solutions dj apportes par des tiers et de comprendre et dexpliquer pourquoi ces solutions ne sont pas valables. Cela demandait ainsi une recherche des solutions existantes et surtout une recherche cratrice pour avoir des solutions nouvelles. Ces recherches se sont faites par le biais de la documentation prsente sur internet mais galement sur des livres. Les diffrentes pages visites ainsi que les diffrents ouvrages utiliss ont t rfrencs dans la webographie et dans la bibliographie Il tait important pour les diffrents points abords ci-dessus de surtout bien confirmer et bien vrifier ses sources. La troisime mthode tait de rechercher des informations au sein mme de lentreprise. Ainsi, afin de bien comprendre et expliquer lexistant, il tait ncessaire dinterviewer des personnes travaillant dans ces diffrents domaines. Il fallait donc pour ce mmoire avoir une entrevue avec un chef de projet informatique dune socit informatique et/ou non informatique. Dautres entrevues taient galement prvoir 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.
Page 35 / 79
Audrey LEPICOUCHE
2007
Afin davoir des rsultats pertinents avec ce type de mthode, la dmarche a t la suivante. Dans un premier temps, il a fallu dcrocher des rendez-vous afin de faire les interviews. Afin de dcrocher des interviews auprs des socits, il a t prvu de faire des demandes de rendezvous par mail afin de toucher le plus grand nombre de personnes ainsi que le plus grand nombre de socit. Le mail qui a t envoy afin de dcrocher 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 prcis est Quelle est la conduite suivre sur le management dun projet, lorsquun changement intervient durant un projet informatique ? . Je vous propose la fin de cette tude de vous faire parvenir les rsultats ainsi que les solutions qui auront t trouves afin de vous en faire profiter mais galement afin de vous remercier du temps que vous maurez accord pour cette interview. Je me permets de vous adresser ce courriel afin que nous puissions convenir dun rendez-vous pour une interview sur la conduite du changement. Je vous propose donc de me contacter afin de prendre un rendez-vous dune dure de 30 minutes selon vos disponibilits. Je vous remercie et je reste votre disposition si vous souhaitez avoir des informations complmentaires. Trs cordialement. Audrey LEPICOUCHE
Ces prises de rendez-vous par le biais de courriel nont pas t fructueuses puisque seul un rendez-vous a pu tre pris sur une quinzaine de demandes faites. Les difficults rencontres concernent plus particulirement le manque de temps quont les personnes ou les entreprises vers qui les courriels ont t envoys.
Page 36 / 79
Audrey LEPICOUCHE
2007
Afin de faire au mieux pour ces interviews, un questionnaire a t labor et les rponses ce questionnaire se trouvent en annexe du mmoire. Voici donc les diffrentes questions qui ont t poses lors des diffrentes interviews :
Cette interview sur la conduite du changement est une des tapes importante dune tude faite pour comprendre quelles sont les conduites suivre sur le management dun projet lorsquun changement intervient durant un projet informatique.
1. Quels sont les types de projets informatiques qui vous sont confis, dveloppement dapplications, mise en place darchitecture rseaux ? 2. Les quipes projet sont composes de combien de collaborateurs en gnral ? 3. Quelle est votre dmarche actuelle pour grer les projets de type informatique ? 4. Une fois que le projet a dbut, vous est-il dj arriv de faire face un changement inattendu ? 5. Comment grez-vous des changements de types humains dans un projet informatique ? a. Changement du chef de projet ? b. Changement dun collaborateur ? c. Les arrts maladies ? d. Les congs pays ? 6. Au niveau technique, comment grez-vous les changements comme les modifications des besoins client impliquant bien souvent un changement de technologie (langage de programmation, architecture rseau ) ? 7. Durant un projet, un chef de projet doit bien souvent rendre compte de son avancement auprs du client, quelle conduite avez-vous face au client lorsque vous devez lui annoncer un retard sur les dlais ? Prenez-vous alors un rle de commercial ? 8. Comment grez-vous des changements au niveau financier dans un projet informatique ? a. Les restrictions budgtaires ? b. Les formations imprvues, dues par exemple un changement de besoin client ? c. Rorganisation ou rachat de la socit, comment grez-vous la continuit du projet sans quil y ait dimpacte pour le client ?
Page 37 / 79
Audrey LEPICOUCHE
2007
9. La mise en production marque bien souvent la fin dun projet, comment grez-vous un changement durant cette phase ? a. Le produit final est non fonctionnel dans lenvironnement client ? b. Le client a chang un quipement dans son architecture remettant ainsi en dfaut le projet ? Je vous remercie de mavoir accord du temps pour cette interview. Je vous ferai pars des rsultats de cette tude la fin de sa ralisation.
Le nombre dinterview slve un. Le rendez-vous a pris une demi-heure environs. Il sest drouls en suivant les questions prpares et prsentes prcdemment dans ce paragraphe. La dernire mthode, mais non la moindre, consistait sappuyer sur le directeur de mmoire ainsi que sur les personnes de la socit daccueil pour la formation du diplme de master en ingnierie informatique, rseaux et tlcoms. La dmarche pour cette mthode a t simple puisquil suffisait de demander un rendez-vous selon la disponibilit des interlocuteurs afin de pouvoir les consulter. La dmarche consistait dans un premier temps denvoyer la rdaction faite afin que le directeur de thse puisse sen imprgner et apporter les commentaires sur le texte dj ralis. Cest donc le directeur de thse qui permet de guider la rdaction, et ainsi de savoir si la rdaction effectue ne sort pas du sujet voqu.
Page 38 / 79
Audrey LEPICOUCHE
2007
6.
Description des amliorations
A ce stade du mmoire, il a t fait un diagnostic de lexistant sur les diffrentes conduites suivies sur le management de projet lorsquun 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 particulirement, de montrer les points faibles des conduites suivies aujourdhui et afin de pouvoir y apporter des solutions. Il a galement t dtaill, la manire dont les recherches ont t effectues afin dobtenir les informations prsentes dans les chapitres prcdents. Lobjectif de ce nouveau paragraphe est de prsenter les amliorations qui peuvent tre apportes afin de faire face aux diffrentes critiques voques lors de lanalyse de lexistant. Afin de faire la prsentation des amliorations, il sera exprim, dans un premier temps, les amliorations souhaitables apporter pour faire face aux diffrents points ngatifs prsents lors de la critique de lexistant. Dans un second temps, il sera mentionn les diffrentes solutions possibles pour pouvoir rpondre ces amliorations souhaites. Pour finir ce paragraphe, il sera prcis et dtaill les solutions damlioration retenues en argumentant et en justifiant ces choix.
6.1
Amliorations souhaitables
Comme il a t vu tout au long de ce mmoire, les projets informatiques touchent tous les domaines importants dune entreprise : les domaines financiers, commerciaux, ressources humaines, techniques Les projets tant trs nombreux et surtout trs diversifis, il a t dcid dans ce mmoire de dcouper les changements, pouvant survenir durant un projet informatique, selon les domaines cits auparavant. Par consquent, plusieurs amliorations sont apporter dans les diffrents domaines.
6.1.1 Les amliorations apporter lors dun changement dans le management humain
Suite lanalyse puis la critique de lexistant, plusieurs points damlioration sont apporter pour faire face de manire irrprochable aux changements dans le management humain. De plus, ces amliorations sont indispensables afin de ne pas arriver des points de non retour et par consquent labandon des projets.
6.1.1.1
Chef de projet
Lorsquun 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 lanalyse et la critique qui ont t dtailles dans les paragraphes prcdents sur la conduite suivre face un tel changement, plusieurs amliorations sont apportes.
Page 39 / 79
Audrey LEPICOUCHE
2007
Tout dabord, 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 mme projet. Afin que ce dernier puisse mener bien cette tche, 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 circules durant le projet. Ceci vite bien entendu quil y ait de la perte dinformation et que toutes les personnes intervenant de prs ou de loin sur le projet puissent tre au mme niveau dintervention que chaque membre de lquipe. Le chef de projet est doc ainsi tenu pour responsable du bon droulement du projet et surtout de la bonne mise en uvre de la gestion de projet. Le second point damlioration concerne plus particulirement la communication orale sur le droulement du projet entre les diffrents acteurs. En effet, il est ncessaire que chaque membre de lquipe projet se runisse afin que le niveau dinformation soit identique pour tous. Ceci permet ainsi, que lorsque le chef de projet change, chaque membre sait ce quil a fait et ce quil lui reste faire, mais chaque membre est galement capable de prsenter le projet dans son intgralit au nouveau chef de projet en lui prsentant les diffrents points dj traits ainsi que les diffrents points restants. Ainsi, ces amliorations sont essentiellement bases 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 prparation permettra de mener bien le projet sans rencontrer de risques trop importants.
6.1.1.2
Collaborateur
Lorsquun changement de collaborateur intervient durant un projet, il faut que certaines choses aient t mises en place afin de pouvoir palier ce changement. Suite lanalyse et la critique qui ont t dtailles dans les paragraphes prcdents sur la conduite suivre face un tel changement, plusieurs amliorations sont apportes. Dans un premier temps, il faut amliorer la composition initiale de lquipe projet afin de faire face au moindre problme de type humain. En effet, comme il a t dtaill dans lanalyse de lexistant, un changement de collaborateur peut intervenir pour plusieurs raisons telles que les dmissions, les congs maladies, les incompatibilits dhumeur, les licenciements Cest pour ces raisons l, quil est ncessaire que le chef de projet, au commencement du projet, prvoit ce type de changement en ajoutant des personnes en plus dans la composition de son quipe. Ces personnes seraient des remplaants capables dintervenir nimporte quel moment du projet afin de faire le remplacement du collaborateur absent. Il est donc impratif que ces personnes assistent aux runions de travail et quils soient au mme niveau dinformations que les membres titulaires du projet. Ainsi, cela vite tout retard sur le projet d des transferts de comptences pour que le nouveau collaborateur soit au mme niveau dinformation que les membres du projet.
Page 40 / 79
Audrey LEPICOUCHE
2007
Dans un second temps, un autre point damlioration concerne le chef de projet. En effet, il est plus courant quil y ait des changements de collaborateur plutt que des changements de chef de projet. Il faut donc que le chef de projet amliore son estimation de la charge de travail du projet. Pour effectuer cette amlioration, il faut que le chef de projet prenne en compte des lments 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 droulement du projet. Cette amlioration permet davoir une meilleure visibilit sur la charge de travail, sur le temps pass et sur le temps restant du projet. Par consquent, le chef de projet la matrise des risques tels que les dlais et les cots.
Les deux amliorations prsentes dans ce paragraphe, qui sont une amlioration concernant la composition de lquipe 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 quun changement de type humain est imprvisible et doit se grer sur le fait accompli. Ces amliorations peuvent remdies certains problmes mais il est impossible de pouvoir prvoir lavance les amliorations apporter pour des changements de type humain.
6.1.1.3
Les arrts maladies
Les arrts maladies sont des vnements imprvisibles quelque soit les personnes. Ces arrts peuvent trs bien tre pris par le chef de projet comme par un collaborateur de lquipe projet. Les critiques qui ont t voques dans les paragraphes prcdents sur les arrts maladies, montrent quil y a un manque dorganisation de la part du chef de projet. Lamlioration 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 prcdent sur les changements de collaborateurs, le chef de projet doit prvoir des membres en plus dans son quipe projet afin de pouvoir palier ce type de changement, dans un souci de ragir plus vite au changement imprvus tels que les arrts maladie de collaborateur. Bien entendu, tous ces lments tournent autour dune amlioration essentielle mettre en place : la communication. En effet, il nest pas utile de samliorer dans lorganisation et la planification sil ny a pas de communication entre les membres de lquipe projet. Cette communication est la base du bon fonctionnement dun projet et plus particulirement de la bonne gestion du projet. Si larrt maladie concerne le chef de projet, lamlioration faire sur la conduite suivie face aux arrts maladies, concerne lorganisation du chef de projet. En effet, comme il a t expliqu dans lanalyse de lexistant, il y a diffrentes types darrts maladies, les courtes, les moyennes et les longues dures. Dans tous les cas, le chef de projet doit avoir organis son projet de telle manire que ces responsables puissent reprendre la gestion du projet sans difficult. La rdaction de documentation, afin de mettre sur papier tous les lments du projet, est trs importante, cette rdaction est une forme de communication crite entre les diffrents membres du projet et le client.
Page 41 / 79
Audrey LEPICOUCHE
2007
Pour rsumer, les amliorations apporter concernant la gestion des arrts maladies concernent lorganisation et la planification du projet par le chef de projet, la rdaction de documentation, et la communication qui est un axe damlioration majeure dans ce mmoire.
6.1.1.4
Les congs pays
Les congs pays sont prvisibles, contrairement aux arrts maladies. Les congs pays permettent donc de prvoir les absences de chacun des collaborateurs et ainsi de pouvoir planifier plus facilement un projet. La planification est donc un point damlioration soulever. En effet, le chef de projet connat tous les paramtres ncessaires pour planifier son projet. Il sait le nombre de jours de congs auxquels ses collaborateurs ont le droit, ainsi que la dure en nombre de jour de son projet. Ainsi, il est impratif que le chef de projet prenne en compte ces diffrents paramtre afin damliorer ses planifications, et viter ainsi tout problme ou tout retard d une mauvaise planification. Plus la planification sera prcise et minutieuse, moins il y aura de risques de retard. Dans ce paragraphe, il y a galement une autre amlioration apporter. Cette amlioration a dj t voque dans les paragraphes prcdents. 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 dposer les dates de leurs futurs congs au commencement du projet. Bien entendu, cette demande concerne essentiellement les congs de longue dure, soit les congs excdant une semaine, ceci afin de faciliter le chef de projet dans la mise en place de ses planifications. Les deux amliorations apporter pour des changements survenant durant les projets informatiques tels que les congs pays sont dune part damliorer la planification du projet de telle sorte quelle soit plus prcise et plus minutieuse, dautre part damliorer une fois de plus la communication entre les diffrents acteurs du projet afin que dans ce cas prcis, les collaborateurs prviennent trs rapidement le chef de projet pour les futurs congs quils souhaitent poser.
6.1.2 Les amliorations apporter lors dun changement dans le management technique
Dans ce paragraphe seront cits les diffrents points damlioration apporter pour faire face aux changements intervenant durant un projet informatique dans le domaine du management technique. Ces amliorations ont t mises en avant suite au paragraphe sur lanalyse de lexistant et plus prcisment 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 vnements peu ordinaires et peu courants puisquils impliquent dans la plupart des cas une refont totale du projet.
Page 42 / 79
Audrey LEPICOUCHE
2007
Dans la rdaction des prcdents paragraphes, dune part sur lanalyse de lexistant, dautre part sur la critique de cet existant, il en ressort plusieurs lments qui sont amens tre amliors. La premire amlioration qui peut tre faite est la mme que celle cite prcdemment, savoir la communication. En effet, dans le cas dun changement de langage de programmation, autrement dit un changement technique, il est important que ds le commencement du projet il y ait une communication importante et rgulire entre les membres de lquipe et le chef de projet. Cette communication rgulire permettrait ainsi au chef de projet de faire face aux questions techniques poses par le client lors des runions de pilotage, mais aussi de comprendre et dexposer au client les consquences dun tel changement durant le projet. La seconde amlioration concerne les connaissances du chef de projet sur les comptences de ces collaborateurs. En effet, il est important que le chef de projet connaisse les comptences techniques quil y a au sein de son quipe projet, ou quil sache les retrouver rapidement. Lorsque le client annonce un tel changement, le chef de projet doit savoir de manire quasi immdiate si dans son quipe projet, il y a des comptences 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 diffrents lments prendre en compte pour le financement de ce changement. En effet, le cot financier sera plus lev si dans lquipe projet actuelle, il ny a pas de comptences dans le nouveau langage de programmation demand par le client, car cela demandera automatiquement lembauche de nouvelle personne comptentes dans le domaine souhait. La troisime amlioration, qui pourrait tre galement prsente dans le paragraphe sur le management humain, concerne le choix des membres de lquipe projet. Le chef de projet pourrait, afin de palier ce type de changement, mais aussi afin davoir une quipe projet multi-comptente, choisir des membres de lquipe avec des comptences multiples sur les langages de programmation. Ainsi, et titre dexemple, le chef de projet pourrait dcider davoir 80% de son quipe avec des comptences multiples en langage de programmation et 20% spcialise dans le langage prvu au commencement du projet. Avec ce type de composition, lors dun changement de type changement de langage de programmation, seule 20% de lquipe serait changer, permettant ainsi de faire des conomies sur les cots. Pour rsumer ce premier paragraphe sur les amliorations faire lorsque des changements dans le management technique surviennent, et plus particulirement lors de changement de langage de programmation, les amliorations releves sont encore et toujours de mieux communiquer, davoir une meilleure connaissance des comptences de chaque membre de lquipe et de faire en sorte de composer une quipe projet pouvant rpondre tous les types de demandes et surtout tous les types de technologies.
6.1.2.2
Changement darchitecture rseau
La critique qui a t faite au chef de projet sur ce type de changement est de ne pas avoir prvu dans son planning les changements darchitecture rseau. Ces changements sont prvus et donc facilement planifiable pour le chef de projet. Lamlioration se porte une fois de plus sur la planification du projet afin de prendre en compte ds le commencement du projet tous les paramtres de ce dernier. Le chef de projet doit prvoir, dans ces actions et dans son planning, du temps afin de prparer ce changement darchitecture rseau afin que le projet puisse continuer sans avoir de surprises. La conduite de changement de management de projets informatique Page 43 / 79
Audrey LEPICOUCHE
2007
Ce changement doit tre pris en compte galement dans les dlais annoncs au client, que ce changement darchitecture soit du ct client ou du ct de lquipe projet. Lamlioration se porte une fois de plus sur la gestion du projet et plus particulirement sur le planning du projet qui doit tre le plus complet et le plus prcis possible.
6.1.2.3
Changement de systme dexploitation
Dans ce paragraphe, le changement technique concern est un changement de systme dexploitation. Les amliorations concernant ce changement ne seront pas toutes dtailles, puisque certaines ont dj t expliques dans les paragraphes prcdents comme dune part une amlioration la composition de lquipe projet et dautre part une amlioration sur la communication. Lamlioration qui va tre dtaille dans ce paragraphe concerne lavenir du projet. En effet, lorsquun projet est termin et quil est en production chez le client, il est important que celui-ci dure dans le temps, tant en terme de qualit quen terme dutilit. Si le client dcide de modifier les systmes dexploitation de sa socit, il faut que le produit dvelopp puisse fonctionner dans le nouveau systme mettre en place. Le chef de projet donc limportante mission de prsenter au client les diffrentes manires de dvelopper son projet mais aussi et surtout la faon la plus pertinente afin que son projet est un avenir qui dure dans le temps. Lamlioration concernant ce type de changement est donc essentiellement base sur lamlioration de la rflexion du projet mais aussi la rflexion sur lavenir du projet afin que celui-ci dure le plus longtemps possible.
6.1.3 Les amliorations apporter lors dun changement dans le management commercial
Dans ce paragraphe seront dtailles les amliorations qui peuvent tre faites pour faire face aux changements intervenant durant un projet informatique dans le domaine du management commercial. Ces amliorations ont t mises en avant suite au paragraphe sur lanalyse de lexistant et plus prcisment suite aux critiques faites sur les conduites suivies lors de ce type de changement. Ces amliorations ont pour but de faire face plus facilement aux changements de types commerciaux mais aussi de pouvoir, par la mme occasion, amliorer les cots et vendre mieux.
6.1.3.1
Lors de la critique de lexistant sur les changements tels que des modifications de primtre, il a t mis en avant le fait quune modification du primtre ncessite certes un cot supplmentaire pour le client mais elle doit galement amener le commercial ngocier ou rclamer au client une modification des dlais prvus initialement au contrat.
Page 44 / 79
Audrey LEPICOUCHE
2007
En effet, une modification de primtre implique ncessairement un ajout ou une suppression dans le primtre dfini initialement. Dans les deux cas, cela demande du temps pour effectuer les modifications demandes par le client. Le temps ncessite de la ressource humaine mais galement de la ressource financire. De plus, puisque ces modifications demandent du temps, cela implique que le temps prvu initialement nest plus bon. Il est donc ncessaire que le commercial fasse une demande de modification des dlais afin, dans un premier temps, dviter les retards sur dlais et dans un second temps, afin dviter de payer des pnalits pour cause de retard sur les engagements.
6.1.3.2
Avenants au contrat
Contrairement au paragraphe prcdent, les avenants au contrat, autres que les modifications de primtre, sont dtaills ici comme des vnements survenant lorsque le projet est termin et quil a dj t mis en production chez le client. Les avenants au contrat signs durant le droulement du projet ne sont pas tudis dans ce paragraphe. Les critiques faites sur la conduite suivie pour faire face ce changement concernent particulirement la manire dont les personnes, reprenant le projet, se renseignent sur les diffrents lments du projet initial. Il avait t dj remarqu dans les paragraphes prcdents quune amlioration est faire sur la rdaction de documentation pour mettre sur crit tous les lments ncessaires pour comprendre le droulement du projet ainsi que tous les paramtres le concernant. Dans le cas des avenants au contrat, il est ncessaire que les personnes reprenant le projet se rfrent aux documentations qui ont t faites initialement afin de gagner du temps sur la comprhension dune part du projet et dautre part sur la comprhension des nouveaux lments demands par le client. Une autre amlioration est apporter dans le cadre dun avenant au contrat. Il est important, avant de faire cet avenant, que le commercial tablisse une runion avec le chef de projet, quil soit nouveau ou non. Il faut imprativement, que le discours soit le mme 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 mme niveau dinformation. La communication entre le commercial et le chef de projet est importante car elle permet dune part que le chef de projet dtermine sa charge de travail sur les modifications demandes par le client et ainsi permet au commercial de ngocier le dlai, dautre part cela permet au chef de projet dapporter de nouvelles ides qui peuvent tre vendues au client par le commercial.
Page 45 / 79
Audrey LEPICOUCHE
2007
6.1.4 Les amliorations apporter lors dun changement dans le management financier
Dans ce paragraphe seront dtailles les amliorations qui peuvent tre faites pour faire face aux changements intervenant durant un projet informatique dans le domaine du management financier. Dans lanalyse de lexistant et dans la critique de celui-ci, les changements qui ont t prsents sont des changements de types restrictions budgtaires, dpenses imprvues ou rachat de socit. Il a t vu que plusieurs critiques lies ces changements et plus particulirement lies aux conduites suivies pour y faire face, ont t faites. Le but de ce paragraphe est donc dapporter des amliorations afin que quil ny ait plus de critiques faire. Ces amliorations permettront par la suite de trouver des solutions mettre en place.
6.1.4.1
Les deux critiques qui ont t soulignes concernant les restrictions budgtaires concernent premirement le budget et plus particulirement sa gestion, et deuximement les techniques pour le projet. Les amliorations qui peuvent tre apportes 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 amliore sa gestion. Il est important de budgter 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 dpense pas tout ce budget car comme il a t vu tout au long de ce mmoire, diffrents types de changement peuvent survenir durant un projet comme un changement de collaborateur ou un changement technique Ces diffrents changements cotent de largent 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 supplmentaire afin de palier ces changements et ainsi cela rduira la marge que la socit 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 comptences internes, des dlais. Le chef de projet est le garant du bon droulement du projet en termes de technique mais aussi en termes de budget et de dlai.
Page 46 / 79
Audrey LEPICOUCHE
2007
6.1.4.2
Dpenses imprvues
Les amliorations apporter concernant la conduite suivie lors de dpenses imprvues sont les mmes amliorations que celles exprimes dans le paragraphe prcdent. En effet pour faire face aux dpenses imprvues, il faut que le chef de projet ait des moyens financiers. Ces moyens sont donns par le budget consacr au projet. Il faut donc que le chef de projet gre son budget afin de pouvoir tout financer, les vnements prvus comme les vnements imprvus. Lamlioration se porte donc sur la gestion du budget par le chef de projet. Comme il a t dit prcdemment, il est le garant du bon droulement du projet quelque soit le domaine.
6.1.4.3
Rachat de la socit
Le rachat dune socit est un vnement rare, peu courant. Lors de lanalyse de lexistant et de sa critique, il en est ressorti quil est difficile de faire face ce type de changement puisque le chef de projet nest, daucune manire, matre des vnements. Il a t mentionn, dans le paragraphe sur la critique de la conduite suivie lors du rachat de la socit, que les critiques faire sont les mmes que celles faites dans les autres paragraphes. En effet, lors dun tel vnement tous les domaines tudis dans ce mmoire sont touchs par ce type dvnement. Il en est donc de mme concernant les amliorations qui peuvent tre faite lors de ce type de changement. La seule amlioration qui peut tre mise en avant est celle concernant la communication. En effet, lors dun tel changement, les diffrents acteurs sont soucieux de leur avenir, ce qui peut avoir des effets ngatifs sur le bon droulement du projet. Ainsi il est trs important que les diffrents acteurs participant au projet communiquent beaucoup, afin de rassurer mais aussi afin de pouvoir continuer faire avancer le projet.
6.1.5 Les amliorations apporter lors dun changement dans le management de production
Dans ce paragraphe seront dtailles les amliorations qui peuvent tre faites pour faire face aux changements intervenant durant un projet informatique dans le domaine du management de production. Les amliorations, qui seront apportes dans ce paragraphe, sont importantes car elles permettront dviter des checs de mise en production et donc elles permettront dassurer la signature des PV de recette entre le client et le chef de projet. Pour rappel, la mise en production est un vnement important puisque cest laboutissement du projet, ce qui implique que chaque partie obtient son d, le produit final pour le client, la rcompense pcuniaire pour la socit responsable du projet. La conduite de changement de management de projets informatique Page 47 / 79
Audrey LEPICOUCHE
2007
6.1.5.1
Lors de la critique de lexistant, quatre points ngatifs ont t mis en avant. Premirement, les phases de test nont pas t prvues par le chef de projet. Deuximement, le chef de projet na pas propos au client de mettre lquipe projet dans ses locaux. Troisimement, le chef de projet na pas prpar le passage de mise en production. En fin la dernire critique est que le chef de projet na pas list les diffrents checs susceptibles dapparatre. A lnumration de ces critiques, diffrentes amliorations peuvent tre apportes afin dy palier. Dans un premier temps, comme dans toutes les amliorations voques jusquici, la communication est lamlioration 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 sentourer est un chef de projet qui limitera les risques dans son projet. Dans un second temps, et comme il a dj t voqu dans les paragraphes prcdents, le chef de projet doit tablir de la documentation afin de prparer au mieux, et en limitant les risques, le passage en production du produit. Cette documentation doit tre riche afin dassurer au mieux ce passage.
6.1.5.2
Un changement darchitecture cliente durant la mise en production du produit final est quasiment identique aux changements techniques survenant durant le projet et voqus dans les paragraphes prcdents. Les amliorations apporter sont par consquents identiques celles voques dans le paragraphe sur le changement de systme dexploitation En effet, lamlioration concernant ce type de changement est essentiellement base sur lamlioration de la rflexion du projet mais aussi la rflexion sur lavenir 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 dure de vie longue puisquil est adaptable.
Page 48 / 79
Audrey LEPICOUCHE
2007
6.2
Solutions possibles
A ce point du mmoire, il a t vu lanalyse et la critique de lexistant ainsi que les amliorations apporter face aux critiques faites sur les diffrentes conduites suivies face aux changements. Lobjectif du chapitre venir est de mettre en place ces amliorations en trouvant des solutions. Ces dernires doivent permettre de mieux grer un projet de faire face aux diffrents changements imprvisibles qui surviennent durant un projet. De plus, ces solutions doivent permettre de minimiser les risques comme les risques de dpassement de dlai, dpassement de budget, dabandon du projet . Les paragraphes qui vont suivre vont donc apporter des solutions concrtes pour mettre en place les amliorations souhaites pour chacun des domaines, humain, technique, commercial, financier et le domaine de mise en production.
6.2.1 Les solutions possibles pour amliorer la gestion de projet

Dans le chapitre consacr aux amliorations, dans chacun des domaines prsents, des amliorations sont apporter au niveau de la gestion du projet en gnrale. Dans ce paragraphe sera donc dtaill les diffrentes solutions possibles pour amliorer la gestion dun projet. Tout au long du mmoire, la critique et lamlioration, la plus souvent voque concerne la communication. La communication est continuellement prsente et se prsente sous diffrentes formes comme les runions de travail, les comits de pilotage, les comits de suivi, la documentation Afin damliorer la communication dans un projet et par consquent amliorer sa gestion, plusieurs solutions sont possibles.
6.2.1.1
La documentation
Une premire solution consiste mettre en place diffrents documents tout au long du projet. Ces documents sont ncessaires pour effectuer une bonne gestion du projet mais aussi afin dassurer le bon droulement de celui-ci. Le premier document mettre en place est lanalyse des besoins. Il est en effet important de bien analyser le cahier des charges fournit par le client afin de comprendre les diffrents lments quil souhaite dans son projet. Le second document est un dossier collaborateur . Ce document, ou plutt ce dossier, comporte tous les curriculum vitae des collaborateurs slectionns dans lquipe projet.
Page 49 / 79
Audrey LEPICOUCHE
2007
Le troisime type de document est le planning. Ce document est le cur du projet puisque cest lui qui permettra de grer le temps et par consquent de grer les dlais. Il y a deux types de planning, un planning dit interne , celui rserv lquipe projet et un planning dit de pilotage , celui prsent au client. Le quatrime document est le plan dassurance qualit (PAQ). Ce document sassure de la bonne qualit du droulement du projet. Tout le long du projet, des documents sont rdigs comme les fiches des tches, les comptesrendus de runion (interne et cliente), les fiches de test, les documentations dinstallation, dadministration et dutilisation, la documentation tout au long du codage. Le dernier document est le cahier de recette. Ce document est prsent au client lors de la mise en production de son projet. Dautres documents peuvent bien entendu tre rdigs 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 mmoire, la documentation est le point essentiel dans la gestion dun projet afin que ce dernier se droule correctement. Mais cela peut galement poser un souci. En effet, il faut connatre lenchainement 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 diffrents enchainements entre les documents mais aussi le principe de chacun. Ce document est une procdure de gestion de projet . Elle permettra de lister dans un premier temps les diffrentes tapes, les enchanements entre chacune delles et les documents qui y sont associs ou qui doivent tre faits. Ces documents, tels que les fiches de test, les documents dinstallation, etc. seront des documents dits applicables . Il existera galement dans cette procdure, des documents dit de rfrence qui seront le plan dassurance qualit, le planning, lanalyse des besoins Cette procdure devra galement signaler o se trouve les diffrents documents utilisables. Elle sera accessible tous les membres de lquipe projet comme le chef de projet, les collaborateurs, les responsables hirarchiques
6.2.1.3
Gestion et stockage de la documentation
Maintenant, il a t mis en place afin damliorer la gestion de projet, diffrents documents rdiger par le chef de projet et par ses collaborateurs, ainsi quun document de rfrence rdig par le chef de projet, permettant de relier ces diffrents documents. Mais il faut mettre disposition de tous les membres de lquipe projet, de manire simple et rapide, ces diffrents documents. Pour cela, et dans un souci de dmarche qualit, il faut mettre disposition de tous membres de lquipe projet un espace de stockage sur lequel chacun des membres pourra accder aux documents rdigs pour le projet. La conduite de changement de management de projets informatique Page 50 / 79
Audrey LEPICOUCHE
2007
Plusieurs solutions sont possibles. La premire solution consiste ce que le chef de projet demande un espace de stockage sur un serveur de fichier avec des droits spcifiques pour chacun des membres de lquipe projet. Ainsi seules les personnes travaillant sur ce projet pourront y accder. Tous les documents devront y tre stocks dans leur dernire version afin de sassurer que tous les membres de lquipe projet sont au mme niveau dinformation. La seconde solution consiste mettre en place un outil de gestion lectronique des documents (GED). Cette solution permet de rfrencer de manire unique chaque document cr mais galement deffectuer un cycle de vie dun document, savoir la rdaction dun document, suivi par sa vrification, son approbation, sa publication et dans certains cas sa rvision.
6.2.1.4
Les diffrentes runions
Derniers points dans lamlioration de la gestion de projet, il sagit des runions mises en place par le chef de projet tout au long du projet. Il existe plusieurs types de runion que le chef de projet peut mettre en place, les comits de pilotage, les comits de suivi, les runions de service. Afin damliorer la gestion de projet et surtout la communication, le chef de projet doit organiser plusieurs runions qui ont chacune un objectif diffrent. Dans un premier temps, le chef de projet doit tablir avec le client des chances pour faire des runions appeles comits de suivi . Les chances peuvent se faire selon les besoins du chef de projet ou selon les besoins du client, elles peuvent se faire de manire mensuelle, trimestrielles Ces comits permettent au chef de projet dinformer le client sur ltat davancement du projet. Ils permettent galement de rgler des points de dtails avec le client sur les dtails du projet, sur les dates cls, sur les aspects commerciaux Dans un second temps le chef de projet doit organiser des runions dites comits de pilotage . Ces comits sont des runions en prsence des responsables hirarchiques du chef de projet et permettent de faire un point sur lavancement du projet. Ces runions peuvent tre comme celles faites avec le client, soient mensuelles, trimestrielles en fonction des besoins de chacun. Lobjectif essentiel de ces comits de pilotage est dobserver plus particulirement la rpartition du budget tout le long du projet, lvolution de la marge en regardant bien si la socit ne dpensent pas plus dargent quelle nen gagne que le projet, de faire la gestion des risques, puis galement de prendre les dcisions touchant directement aux finances du projet. En troisime point, le chef de projet doit organiser avec son quipe projet une runion hebdomadaire afin dassurer un suivi technique de lavancement du projet. Cette runion permet donc chacun de fournir un tat davancement des diffrentes tches qui lui sont attribues.
Page 51 / 79
Audrey LEPICOUCHE
2007
Cela permet galement au chef de projet de pouvoir donner dautres tches ses collaborateurs, dtablir des plans daction 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 comits de suivi et de pilotage En dernier point, le chef de projet peut, et la demande de ses collaborateurs, organiser et surtout planifier des runions de travail entre les collaborateurs. Ces runions ont pour objectif en cas de problme technique, de runir les personnes ayant les comptences ncessaires pour rsoudre le problme rencontr par lun des collaborateurs. Ces runions peuvent tre demandes que dans des cas vraiment critique et o il est important dallier toutes les comptences pour avancer le plus vite et viter ainsi les dpassements de dlai.
6.2.1.5
La communication par messagerie
Dans les paragraphes prcdents, il a t expliqu quelles solutions peuvent tre mises en place afin damliorer la communication au sein du projet. Une dernire solution est galement mettre en place. Il sagit de crer une messagerie lectronique commune tous les membres du projet. Ainsi, tous les membres peuvent communiquer par mls en crivant une bote ml unique. Tous les membres peuvent alors avoir le mme niveau dinformation et peuvent consulter les mls consacrs au projet tout moment. Il est noter, que les messageries utilises dans les socits sont des messageries qui offrent des fonctions supplmentaires comme un calendrier, un rpertoire Les deux fonctions cites permettent damliorer la communication lors dun projet. Dans le cas du rpertoire, tous les contacts du projet sont mis dans ce rpertoire et ils sont ainsi accessibles tous les membres du projet. Le cas du calendrier est identique celui du rpertoire. Le chef de projet peut ainsi mettre disposition sur la messagerie commune le planning interne du projet. Cette partie sera dtaille ultrieurement.
6.2.2 Les solutions possibles lors dun changement dans le management humain
Dans le paragraphe du management humain, plusieurs amliorations mettre en place ont t voques afin damliorer la conduite suivie lorsquun changement dans le management humain intervient durant un projet informatique. Afin de mettre en place ces amliorations, diffrentes solutions sont envisageables afin damliorer tout dabord les aspects de composition de lquipe projet mais galement les aspects des plannings incluant les congs, les dates cls ainsi que leur mise disposition aux diffrents acteurs La conduite de changement de management de projets informatique Page 52 / 79
Audrey LEPICOUCHE
2007
6.2.2.1
Composition de lquipe projet
En premier point, la composition de lquipe projet est faite par le chef de projet en fonction des comptences des personnes, et des diffrentes technologies qui seront utilises tout au long projet. Ainsi le chef de projet doit, en fonction de la charge de travail estime ainsi que des dlais prvus pour le projet, faire une estimation sur leffectif dont il a besoin sur le projet. Le choix des membres de lquipe projet se porte principalement sur leurs comptences. La composition de l quipe peut se faire de diffrentes manires et ce choix en revient au chef de projet. Premirement, le chef de projet peut choisir de prendre des personnes spcialises dans leur domaine permettant ainsi davoir des comptences fortes avec des possibilits davances importantes. Chacun des membres se verra alors attribuer les modules dont les technologies sont dans leur spcialit. Deuximement, le chef de projet peut dcider de choisir des personnes multi-comptentes sur les technologies utilises durant le projet. Le chef de projet peut alors attribuer la plupart des modules du projet tous les membres de lquipe. Par contre, comme il a t vu dans les paragraphes prcdents, afin de palier certain changement de management humain, il est essentiel que le chef de projet prvoie du personnel supplmentaire. Ce personnel serait susceptible de remplacer les diffrents membres de lquipe en cas dabsence comme les congs maladies, les congs pays, les dmissions Il existe diffrentes manires daborder le nombre de remplaant prendre pour chacun des projets. Une solution serait que le chef de projet choisisse de prendre une personne en plus par technologie utilise. Ainsi, si le projet utilise, par exemple, deux langages, le chef de projet doit alors prendre deux personnes supplmentaires 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 lquipe projet doit tre constitue de dix personnes et quil a tabli que le pourcentage de remplaant pour son projet slve 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 remplaants participent toutes les runions pour lesquelles les collaborateurs sont concerns. Cette prsence est ncessaire et obligatoire afin de sassurer que les remplaants soient au mme niveau dinformation que les autres membres de lquipe. Le temps durant lequel le remplaant ne participe pas au projet, savoir le temps en dehors des runions ou des remplacements, est utilis pour le travail au quotidien de la socit.
Page 53 / 79
Audrey LEPICOUCHE
2007
6.2.2.2
La planification
La planification dun 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 dtaill dans ce paragraphe sera celui consacr aux collaborateurs, savoir le planning interne, puisque les amliorations apporter concernent les changements survenant dans le management humain durant le projet. Le planning de pilotage nest donc pas concern dans ce paragraphe. Dans un premier temps, le chef de projet doit sattacher dtailler de manire trs prcise le planning interne en indiquant les diffrents membres avec pour chacun les diffrents modules traiter ainsi que les dates de dbut et de fin pour chacun de ces modules. Le chef de projet doit galement faire apparatre sur ce planning les dates de congs pays prises par chacun ainsi que les dates de formation, sil y en a. Derniers points faire apparatre sur le planning, sont les dates cls du projet afin que chacun des membres soient au mme niveau dinformation que le client. Concernant les congs pays, le chef de projet doit mettre en place un systme lui permettant de connatre ds le commencement du projet ou suffisamment tt, les dates de congs de chacun de ses collaborateurs. Pour cela, plusieurs solutions soffrent lui. Premirement, en fonction de la dure du projet, il peut demander ces collaborateurs lors de la premire runion, celle dinitiation, que chacun deux lui donne ces congs pays dans un dlai dune semaine ou la demande du chef de projet dans le cas de projet de longue dure. Cela permet ainsi de pouvoir planifier tout le projet ds son commencement. Deuximement, le chef de projet peut demander ce que ces collaborateurs lui donnent leurs congs au minimum deux mois avant la date souhaite, ceci permettant au chef de projet de pouvoir replanifier le projet en fonction de ces nouvelles donnes. Cela permet de laisser plus de libert aux collaborateurs, et le dlai de deux mois permet galement au chef de projet de pouvoir se retourner et de ne pas se retrouver en dfaut face ce type de changement. Dans un second temps, le chef de projet doit mettre disposition le planning tous les membres de lquipe projet afin que chacun puisse le consulter tout moment. Pour cela, le chef de projet a deux solutions. Premirement, il peut faire son planning par le biais dun tableur comme lapplication Excel. Ce fichier serait alors stocker sur un serveur de fichier au mme endroit que le reste des documents du projet. Deuximement, le chef de projet peut utiliser une application prsente pour chaque membre du projet, la messagerie. En effet, les messageries utilises dans les socits sont toutes dots dun calendrier personnel qui peut tre partag. Il est galement possible comme il a t vu prcdemment de crer une bote gnrique laquelle tous les membres ont accs. Cette bote contient elle aussi un calendrier qui est donc accessible par toutes les personnes autorises utiliser cette bote gnrique. La conduite de changement de management de projets informatique Page 54 / 79
Audrey LEPICOUCHE
2007
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 diffrents membres du projet. Ils ont donc accs tout moment aux informations ncessaires sur les travaux qui leurs sont confis.
6.2.3 Les solutions possibles lors dun changement dans le management technique
Dans le paragraphe consacr aux amliorations faire dans le management technique, plusieurs amliorations ont t voques afin que la conduite suivie, lorsquun changement dans le management technique survient durant un projet, soit amliore. Dans ce paragraphe, vont tre voques les diffrentes solutions pouvant rpondre aux amliorations voques auparavant. La premire solution est un complment dune solution voque dans le paragraphe sur la gestion de projet, le dossier collaborateur (6.2.1.1). Ce dossier permet davoir toutes les informations ncessaires sur les membres composant lquipe projet. Pour complter cette solution, dtaille dans le paragraphe sur la gestion de projet, et afin damliorer le management technique, il faut que les informations concernant les comptences techniques prsents dans chacun des dossiers collaborateurs soient intgrs dans une base de donnes. Cette intgration permettra de ressortir uniquement les comptences techniques en cas de changement dans le domaine technique. De plus cette base de donnes sera accessible par toutes les personnes de la socit, et pourra donc tre utilise pour constituer dautres quipes sur des nouveaux projets ou pour embaucher de nouvelles personnes ayant des comptences non rpertories dans la socit.
La seconde solution prsente dans ce paragraphe concerne les changements darchitecture rseau qui ont t voqus tout au long de ce mmoire. Dans un cas comme celui l, et comme il a t prcis dans le paragraphe sur les amliorations, le chef de projet doit imprativement planifier ce type de changement et plus particulirement lorsquils sont prvus. Pour ce faire, le chef de projet doit mettre en place une documentation montrant comment effectuer la bascule entre lancienne architecture rseau et la nouvelle, ce sont les modes opratoires. Ces documents doivent tre prpars et tests plusieurs fois afin de sassurer quil ny a pas derreur. Une fois ces modes opratoires rdigs, le chef de projet doit planifier des phases de tests de bascules avant deffectuer la migration dfinitive. Deux possibilits soffrent cette solution, soit lquipe projet rdige le mode opratoire et le chef de projet prvoit deux phases de tests. Si ces deux phases sont valides alors le mode opratoire est approuv. Soit le mode opratoire est dcoup en plusieurs modules qui sont tests au fur et mesure. Une fois tous les modules tests, le chef de projet planifie une phase de test globale. Si cette phase est valide alors le mode opratoire est approuv.
Page 55 / 79
Audrey LEPICOUCHE
2007
Dans les deux cas, aprs chaque phase de tests quelles soient globales ou non, le testeur doit remplir une fiche de test permettant de lister toutes les anomalies rencontres lors des tests.
6.2.4 Les solutions possibles lors dun changement dans le management commercial
Dans ce paragraphe seront dtailles les solutions qui peuvent tre mise en place afin de rpondre aux amliorations qui ont t voques dans les chapitres prcdents sur le management commercial. Dans les chapitres prcdents, lanalyse et la critique de lexistant ainsi que les amliorations ont t fait pour deux changements, les modifications de primtre et les avenants au contrat. Concernant les modifications de primtre, les solutions apporter concernent essentiellement les procdures suivre, par le commercial et le chef de projet, face aux demandes de changement de primtre faites par le client. Premirement, lorsque le client annonce son souhait de modifier le primtre prvu initialement, il a t vu dans les amliorations apporter, quil faut imprativement que le commercial ngocie un changement des dlais prvus initialement afin de prendre en compte ce changement de primtre. Pour cela, et afin de faciliter le travail du commercial, il faut crire des pr-requis lorsquun changement de primtre survient durant un projet. Ces pr-requis doivent tre applicables quels que soit le projet. Dans ce pr-requis doivent apparatre que pour tout changement de primtre, la socit responsable du projet se donne un dlai de sept jours maximum pour donner au client le temps ncessaire dont lquipe projet a besoin pour rpondre sa demande. Ce dlai est alors accept ou non par le client. Une ngociation doit alors se faire le cas chant. Deuximement, et dans le cadre des avenants au contrat, les solutions mettre en place sont quivalentes celles voques dans le 6.2.1. En effet, afin damliorer la conduite suivie lorsquun avenant au contrat est annonc, il faut amliorer la communication. Ce sont donc des solutions telles que la rdaction de documents tout le long du projet initial, le suivi du projet qui doivent tre mises en place afin que lors de lapparition davenants au contrat, les futurs collaborateurs et responsables de projet aient un niveau dinformation assez important afin de pouvoir rpondre cet avenant. De plus, comme dans la premire solution voque dans ce paragraphe, il faut, lors de la signature de lavenant avec le client, que le commercial ngocie un dlai afin dinformer le futur chef de projet de la signature dun avenant, et lui laisser le temps de prendre connaissance du projet et pouvoir dfinir la charge de travail quil faut pour rpondre la demande du client.
Page 56 / 79
Audrey LEPICOUCHE
2007
6.2.5 Les solutions possibles lors dun changement dans le management financier
Dans le paragraphe sur le management financier, plusieurs amliorations mettre en place ont t voques afin damliorer la conduite suivie lorsquun changement dans le management financier intervient durant un projet informatique. Afin de mettre en place ces amliorations, diffrentes solutions sont envisageables afin damliorer tout dabord la conduite suivie lorsque des restrictions budgtaires interviennent durant un projet informatique, mais galement la conduite suivie lorsque le changement intervenant durant le projet est le rachat dune socit. Premirement, concernant les restrictions budgtaires deux solutions sont envisageables afin de faire face un tel changement. La premire solution consiste ce que le chef de projet, linitial du projet, mette par crit la rpartition prvue du budget qui lui a t accord. Une fois cette rpartition faite, le chef de projet le fait valider par sa hirarchie afin que, dune part ses responsables soient au courant de la rpartition du budget, dautre part que les responsables assurent au chef de projet par leur validation que le budget ne changera pas. Cette validation permet ainsi de protger le budget prvu quelques soient les restrictions budgtaires qui sont mises en place. La seconde solution consiste ce que le chef de projet lors de linitialisation 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 prvu pour mener bien le projet puis le budget prvu pour les risques qui peuvent survenir de manire inattendu durant le projet. Par consquent, le chef de projet demande ses responsables un budget suprieur au budget ncessaire ce qui lui permet ainsi de pouvoir faire face aux restrictions budgtaires qui sont comprises dans le budget dans la partie risque. Deuximement, concernant le rachat de socit, il ny a pas de solutions spcifiques supplmentaires mettre en place pour faire face ce type de changement mises part les solutions voques prcdemment.
6.2.6 Les solutions possibles lors dun changement dans le management de production
Dans ce paragraphe seront dtailles les solutions qui peuvent tre mise en place afin de rpondre aux amliorations qui ont t voques dans les chapitres prcdents sur le management de production. Deux types de changements ont t voqus dans lanalyse de lexistant consacr aux changements dans le management de production, un changement de type produit final non fonctionnel et un second de type architecture cliente modifie . Les solutions qui peuvent tre mises en place concernant le premier type de changement, savoir le produit final non fonctionnel, sont les mmes solutions que celles cites prcdemment sur la gestion de projet (6.2.1). La conduite de changement de management de projets informatique Page 57 / 79
Audrey LEPICOUCHE
2007
En effet, afin damliorer la communication, pour palier ce type de changement, il faut que le chef de projet fasse le ncessaire, comme expliqu dans le 6.2.1, pour que de la documentation soit rdige 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 rdaction de documentation, de lorganisation de runions Dans le paragraphe dtaillant les amliorations apporter, il a t clairement voqu que le chef de projet doit lorsquil est nomm sur un projet, faire en sorte dtablir un produit final qui puisse vivre dans le temps. Par consquent, le produit final doit pouvoir fonctionner, moyennant des modifications minimes, dans tous les environnements, puis il doit pouvoir rpondre aux ventuels besoins futur du client. Ainsi, le chef de projet sassure de pouvoir faire face aux changements de type architecture cliente modifie . Pour cela plusieurs solutions peuvent tre mise en place afin de palier ce type de changement. La premire solution consiste faire un point avec le client sur les souhaits davenir de son projet. Ce point permettra au chef de projet de constituer les diffrents modules de telles sortes que ces derniers soient maintenables et par consquent modifiables en fonction des nouveaux besoins. De plus, le chef de projet doit galement se renseigner auprs du client sur les ventuels changements darchitecture quil pourrait faire, savoir si le client a projet court, moyen ou long terme des modifications darchitecture. Si tel est le cas, le chef de projet doit demander au client de lui fournir les informations ncessaires 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 matriels utiliss par le client. En effet, le client a dans sa socit du matriel provenant dun ou plusieurs constructeurs. Lobjectif du chef de projet est de prendre contact avec ces constructeurs afin de se renseigner sur les volutions venir du matriel 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 damlioration
Dans le chapitre prcdent, il a t dtaill les diffrentes solutions qui peuvent tre mise en place afin damliorer les diffrentes conduites suivies face aux nombreux changements qui peuvent survenir durant un projet informatique. Toutes les solutions prsentes sont toutes des solutions exploitables mais certaines de ces solutions sont plus pertinentes. Par consquent, cest dans ce paragraphe que vont tre mises en avant les solutions retenues afin damliorer les conduites suivies, durant les projets informatique, face au changement.
Page 58 / 79
Audrey LEPICOUCHE
2007
6.3.1 La gestion de projet

Comme il a t expliqu tout au long de ce mmoire, les diffrents changements pouvant survenir durant un projet informatique, mettent dans la quasi totalit des cas, la gestion de projet en dfaut. Les solutions retenues afin damliorer la gestion dun projet et ainsi pouvoir faire face aux diffrents changements vont tre slectionnes dans ce paragraphe. Il a donc t choisi de prendre la totalit des solutions voques dans le 6.2.1. Par consquent, concernant la partie documentation, il est retenu de mettre en place les documents essentiels qui sont lanalyse des besoins, les dossiers collaborateurs, les plannings, le plan dassurance qualit, le cahier de recette, les fiches de tests, les fiches des tches et les documentations dinstallation, dutilisation et dadministration. Bien entendu, ces documents peuvent tre accompagns dautres documents en fonction des besoins sur le projet. Il a t galement retenu de faire une procdure permettant de mettre en relation tous les documents faits pour le projet et durant le projet. En troisime point, il a t choisi de mettre en place la solution de loutil 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 amliorer la conduite suivi pour la gestion de projet face aux changements, dorganiser plusieurs type de runions quelque soit le projet. Ainsi, chaque semaine, une runion de travail sera organise par le chef de projet afin de faire un suivi sur lavancement du projet, mais aussi afin davoir des remontes de problmes rencontrs par les diffrents collaborateurs. Chaque runion doit au final aboutir sur un plan daction et devra tre suivie par un compterendu envoy chacun des participants, plus dautres 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 ltat davancement du projet, et de pouvoir remonter les diffrents problmes ou besoin de part et dautre. Pour terminer, un comit de pilotage devra tre organis par le chef de projet avant chaque date cl du projet afin de faire ltat davancement du projet avec les responsables hirarchiques du chef de projet.
6.3.2 Le management humain

Sur les aspects de management humain, il va tre dtaill les solutions qui ont t retenues pour amliorer les conduites suivies face aux changements dans ce type de management. Concernant la composition de lquipe projet, les solutions choisies sont les suivantes. Premirement la composition de lquipe projet doit se faire avec des personnes multicomptentes afin de pouvoir attribuer nimporte quel module nimporte quel membre de lquipe projet. La conduite de changement de management de projets informatique Page 59 / 79
Audrey LEPICOUCHE
2007
Deuximement, concernant le nombre de remplaant, la solution choisie est de prendre le nombre de remplaant en fonction dun pourcentage fix par le chef de projet au commencement du projet, comme expliqu dans le 6.2.2.1. Enfin, les remplaants doivent imprativement participer aux runions davancement du projet. Concernant la planification, les solutions choisies sont les suivantes. Premirement, le chef de projet doit demander chacun de ces collaborateurs de lui fournir les dates des congs pays quils souhaitent prendre, hors journes occasionnelles, ds le commencement du projet ou la demande du chef de projet dans le cas de projet de longue dure. Ainsi cela permet au chef de projet de pouvoir planifier le projet ds son commencement. Deuximement, le planning sera mis disposition de chacun des membres par le biais du calendrier dune messagerie commune. De plus, toutes les communications crites concernant le projet devront tre faites partir de cette messagerie commune. Chaque membre de lquipe projet aura donc accs tous les messages concernant le projet ainsi quau planning.
6.3.3 Le management technique

Les solutions proposes pour des changements intervenant sur le management technique ont t slectionns afin quil en ressorte les plus pertinentes. Afin damliorer les conduites suivies face un changement dans le management technique durant un projet informatique, les solutions mettre en place sont les suivantes. Tout dabord, la premire solution retenue est la constitution dune base de donnes sur les informations administratives et les comptences techniques de chaque employ de la socit. Cette base de donnes permettra davoir un panel des comptences existantes au sein de lentreprise mais galement de pouvoir constituer des quipes projet plus rapidement en fonction des comptences de chacun. De plus, la seconde solution retenue, concerne la prparation de la bascule dune architecture lautre. Pour cela, il a t retenu que le mode opratoire de la bascule sera dcoup en plusieurs modules qui seront tous tests sparment. Une fois tous ces tests effectus, une phase de tests globale sera planifie par le chef de projet afin de sassurer que le mode opratoire est valide. Chaque test effectu sera suivi dune fiche de test remplir permettant de lister toutes les anomalies rencontres lors des tests.
6.3.4 Le management commercial

Dans ce paragraphe vont tre dtailles les solutions choisies pour amliorer les conduites suivies lorsque des changements dans le management commercial interviennent durant des projets informatiques. La premire solution choisie concerne les modifications de primtre. En effet, il a t retenu de mettre en place et par crit des pr-requis lors de changements de primtre. La conduite de changement de management de projets informatique Page 60 / 79
Audrey LEPICOUCHE
2007
Ces pr-requis permettant dune part au commercial de pouvoir ngocier plus facilement des dlais, et dautre part au chef de projet de pouvoir planifier sans pression le travail effectuer pour rpondre la demande du client. La deuxime solution retenue concerne les avenants au contrat. Cette solution a dj t voque auparavant. En effet, les solutions mettre en place sont celles dtailles 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 trouves afin de pouvoir amliorer 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 amliorations vont tre dtailles dans ce paragraphe. La premire solution qui a t retenue concernant les restrictions de budget est que le chef de projet fasse lestimation 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 socit et comme il a t expliqu dans tous les paragraphes traitant ce changement, toutes les solutions voques dans ce chapitre sont prendre en compte, ou plus exactement mettre en place lorsquun tel changement intervient durant un projet.
6.3.6 Le management de production

Dans ce paragraphe vont tre voques les solutions qui sont retenues afin damliorer les conduites suivie face aux changements dans le management de production. Premirement, comme pour tous les autres types de management, la premire solution est celle voque dans le paragraphe 6.3.1 sur la gestion de projet. Il est en effet ncessaire de mettre en place les moyens ncessaires pour amliorer la gestion de projet et la communication durant un projet. Deuximement, concernant lvolution dans le temps du projet, les solutions voques dans le 6.2.6 sont toutes les deux retenues, savoir que le chef de projet doit sentretenir aussi bien avec le client quavec les constructeurs afin de connatre pour chacun deux 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 mmoire les diffrentes conduites qui sont aujourdhui suivies pour faire face aux changements. De cet existant, il a t effectu une analyse critique de lexistant, puis il a t apport les diffrentes amliorations qui pouvaient tre faites. La conduite de changement de management de projets informatique Page 61 / 79
Audrey LEPICOUCHE
2007
De ces amliorations il en est ressorti des solutions qui ont t slectionnes afin de garder essentiellement les solutions les plus pertinentes. Dans ce paragraphe, il va tre expliqu pourquoi les solutions cites dans le chapitre prcdent ont t retenues.
6.4.1 La gestion de projet

Concernant la gestion de projet, il a t dcid de garder la solution concernant les diffrents documents rdiger car cest la base pour effectuer une bonne gestion de projet. En effet, mme si les informations sont connus de tout le monde, il est important que ces informations soit retranscrit de manire manuscrite afin dans un premier temps den garder une trace crite et ainsi davoir des justificatifs en cas de problme. De plus, un projet termin peut trs bien tre amen tre modifier par des avenants au contrat, plusieurs annes aprs sa mise en production. Par consquent, il est important de tout mettre par crit afin de pouvoir rcuprer toutes les informations qui ont circules durant le projet initial. Il est galement noter, que la documentation fait partie des livrables qui peuvent tre rclam par le client. Certes tous les documents ne sont pas forcment fournir au client comme les comptes-rendus des runions internes mais la plupart des documents peuvent tre rclams. Il faut donc les rdigs pour pouvoir les fournir au client. Concernant la procdure mettre en place pour faire la liaison entre les diffrents documents prsents dans le projet. Il est important de la faire car ce document permet dorganiser la documentation lie au projet mais galement ce document permet de centraliser les informations au mme endroit. Au sujet de loutil de gestion lectronique des documents, ce choix sest port sur la GED car cest un outil qui permet de grer automatiquement les versions de document. De plus cet outil est dot dun systme de workflow qui permet de faire passer chaque document rdig dans un processus de validation. Cela permet ainsi davoir 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 dposer des documents lis au projet, ce qui vite de se poser des questions sur la validit des documents. Enfin, concernant les runions organises par le chef de projet, il est important den faire autant par soucis de communication. Il est important que chaque acteur li au projet, comme les collaborateurs, le client ou les responsables hirarchiques, soient au mme niveau dinformation sur ltat davancement du projet. Par contre, il est important de faire des runions diffrentes car lordre du jour de chaque runion sera diffrent en fonction des personnes assistant la runion.
Page 62 / 79
Audrey LEPICOUCHE
2007

Le choix concernant la composition de lquipe projet sest port sur des membres tous multicomptents. La justification de ce choix est, quil est important que chaque membre de lquipe projet puisse travailler sur un module ou quil puisse prendre le module dun de ces collgues. De plus, cela permet chacun des membres du projet de pouvoir toffer ses domaines de comptences techniques et dacqurir ainsi plus dexprience professionnelle et plus dexpertise sur les technologies utilises durant le projet. Enfin, dun point de vue financier, un expert cote plus cher quune personne multi-comptente puisque cette dernire nira pas aussi loin quun expert dans son dveloppement ou elle mettra plus de temps quun expert pour trouver des solutions. Par contre en cas de changement de technologie, une personne multi-comptente saura sadapter ce qui nest pas le cas dun expert. Le choix de la seconde solution retenue pour la composition de lquipe sest port sur le nombre de remplaant choisi en fonction dun pourcentage choisi par le chef de projet sur l quipe initiale. Cette solution a t choisie car elle est moins coteuse que de prendre un remplaant par technologie utilise. Dans ce dernier cas, il faudrait prendre des experts et comme il a t expliqu juste avant, un expert cote cher et il nest plus comptent en cas de changement de technologie dans un domaine qui nest pas le sien. De plus, prendre un nombre de remplaant sur un pourcentage de lquipe initial permet davoir un nombre plus ou moins important de remplaants en fonction de la taille du projet et par consquent de la taille de lquipe projet. Concernant les choix faits sur la planification du projet, ils ont t faits par soucis defficacit. En effet, de possder les dates de congs de tous les membres de lquipe projet au commencement de celui-ci ou la demande du chef de projet dans le cas de projet de longue dure, cela permet au chef de projet de pouvoir sengage de manire sre et quasi dfinitive sur les dates cls du projet. De plus, en fonction des congs de chacun, le chef de projet peut attribuer les modules en fonction des priodes dabsence et en fonction de la charge de travail prvue pour chaque module. Concernant le choix fait pour la mise disposition du planning aux membres de lquipe ainsi que pour la communication durant le projet, il sest port sur la messagerie de groupe car lheure daujourdhui toutes les socits sont en possession dune messagerie de groupe qui permet de communiquer mais aussi qui permet de planifier ces journes. Cest donc une solution pratique connue de tous les membres de lquipe mais cest galement une solution peu coteuse puisquelle est dj utilise par la socit. Il ny a donc pas de dpenses faire.
Page 63 / 79
Audrey LEPICOUCHE
2007

Les solutions choisies pour amliorer les conduites suivies face au changement dans le management technique durant un projet informatique concerne premirement la mise en place dune base de donnes unique sur les informations administratives et les comptences techniques de chaque employ et deuximement lorganisation des phases de tests dun projet. Dans le premier cas, le choix qui a t fait sest essentiellement bas sur lutilit et lefficacit de mettre en place une base de donnes. Elle permet davoir un historique et un panel des comptences prsentes au sein de la socit. De plus elle permet de faciliter le travail des chefs de projet lors de la composition de leur quipe. Par ailleurs, cette base de donnes est un pont dentre et de recherche unique pour toutes les personnes ayant besoin de renseignements sur les comptences techniques qui existent au sein de la socit. Concernant lorganisation des phases de tests, il a t choisi de tester sparment chaque module car cela permet de faire ces tests de manire rapide et non fastidieuse. En effet, il suffi de demander chacun des membres de tester le module qui a t dvelopper et cela vite ainsi quun seul membre test tous les modules. Cela permet donc un gain de temps et par consquent un gain dargent.

Dans ce paragraphe, il va tre expliqu pourquoi le choix de la solution sest porte sur la rdaction dun document annonant les pr-requis lorsquun 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 mthodes utilises par la socit pour mettre en place les modifications de primtre tout comme les avenants au contrat. Ce document permet donc de pouvoir ngocier plus facilement avec le client les dlais dexcution et ainsi viter les dpassements de dlais et par consquent viter le paiement de pnalits pour non respect du contrat.

Il va tre abord dans ce paragraphe lexplication du choix quil a t fait pour constituer un budget de dpart. Il a t choisi de budgter dans le projet la part de risques. Ce choix sexplique tout simplement par le fait quil vaut mieux prvoir un budget plus important au dpart au risque quil reste de largent la fin du projet plus que de prvoir au plus juste et risquer de se retrouver financer des lments qui ntaient pas prvus au budget. Cela permet donc dviter ou plutt de minimiser les risques de diminution de marge sur les contrats signs. La conduite de changement de management de projets informatique Page 64 / 79
Audrey LEPICOUCHE
2007

Le paragraphe concernant le choix des solutions pour le management de production est compos de toutes les solutions qui avaient taient proposes dans le 6.2.6. Ce choix sexplique par le fait que le client ou le constructeur sont deux entits compltement diffrentes et quil est important de les consulter quelque soit le projet. En effet, lorsque le client aura dcid de faire voluer son architecture, il sadressera automatiquement son ou ses constructeurs afin de savoir et de comprendre comment il peut faire voluer son architecture. Il est donc important pour lquipe projet de connatre dune part les volutions souhaites par le client, et dautre part les possibilits dvolutions que le ou les constructeurs peuvent proposer au client.
6.5
Description dtaille de la solution choisie
Dans ce paragraphe vont tre dtailles de manire plus prcise les solutions choisies dans les paragraphes prcdents.
6.5.1 La gestion de projet 6.5.1.1 La documentation
Les documents choisis dans le paragraphe 6.3.1 vont tre dtailles ici afin den comprendre clairement leur utilit mais aussi quand ces documents doivent intervenir dans un projet informatique. Le premier document choisi est lanalyse des besoins. Ce document est le premier document rdig par la socit en charge de faire le projet. De plus cette analyse est faite par le chef de projet de manire grossire afin, dans un premier temps de comprendre les besoins du client puis dans un second temps de bien lister les technologies qui seront utilises durant son projet afin de pouvoir choisir ces collaborateurs. Ce document est donc le fruit de lanalyse du cahier des charges fournit par le client et permet de comprendre les diffrents lments que le client souhaite avoir au final de son projet. Ce document permet galement au chef de projet la fin du projet de sassurer que tous les lments qui taient dtaills dans le cahier des charges ont bien t dvelopps. De plus, ce document sur lanalyse des besoins fera lobjet dun comit avec le client afin de sassurer que tous les besoins de ce dernier ont bien t pris en compte. Le second document est un dossier collaborateur . Ce document, ou plutt ce dossier, comporte tous les curriculum vitae des collaborateurs slectionns dans lquipe projet. Ces CV sont formats selon une trame unique, celle de la socit, ce qui permet davoir les informations uniquement ncessaires la socit. La conduite de changement de management de projets informatique Page 65 / 79
Audrey LEPICOUCHE
2007
En effet, dans le cadre du dossier collaborateur , certaines informations comme les socits dans lesquels ont travaills les collaborateurs auparavant, ne sont pas ncessaires. Le but de ce dossier nest pas dembaucher des personnes mais simplement de slectionner des collaborateurs en fonction de leurs comptences. Le troisime type de document est le planning. Ce document est le cur du projet puisque cest lui qui permettra de grer le temps et par consquent de grer les dlais. Comme expliqu auparavant dans le mmoire, il y a deux types de planning, un planning dit interne , celui rserv lquipe projet et un planning dit de pilotage , celui prsent au client. Le planning interne entrera dans les dtails et prsentera les diffrents modules du projet, le temps imparti pour chaque module et les personnes slectionnes pour travailler sur chacun deux. Seront galement prsents sur le planning interne, les congs, les formations ainsi que les diffrentes runions de travail organises par le chef de projet. Le second planning, celui dit de pilotage est utilis pour montrer au client le droulement prvu pour le projet. Dans ce planning apparatra essentiellement les dates importantes, comme le commencement du projet, les phases de test, la recette, la mise en production, les comits de pilotage. Le quatrime document est le plan dassurance qualit (PAQ). Ce document sassure de la bonne qualit du droulement du projet mais aussi et surtout ce document est le fil conducteur du projet, cest un rfrentiel commun. Il et mis disposition de tous les acteurs du projet permettant dassurer ainsi la qualit du projet ainsi que la qualit du suivi. Tout le long du projet, des documents sont rdigs comme les fiches des tches permettant de dtailler les diffrents modules et le travail effectuer pour chacun, les comptes-rendus de runion (interne et cliente), les fiches de test pour chaque module finalis, les documentations dinstallation, dadministration et dutilisation, la documentation du codage lorsquil sagit du dveloppement dun produit. Le dernier document est le cahier de recette. Ce document est prsent au client lors de la mise en production de son projet. Ce document linforme des lments qui ont t fait et ceux quil reste faire si cest le cas. Il comporte galement les diffrentes fiches de test permettant de prouver au client que les diffrents modules attendus fonctionnent. Dautres documents seront bien entendu rdigs par le chef de projet ou ces collaborateurs selon les besoins et en fonction du droulement du projet
6.5.1.2
Utilisation de la documentation
La solution qui a t retenue concernant lutilisation de la documentation est la procdure de gestion de projet . Comme il a t vu dans le paragraphe 6.2.1.2, la procdure de gestion de projet permet de lister dans un premier temps les diffrentes tapes, les enchanements entre chacune delles et les documents qui y sont associs ou qui doivent tre faits. La conduite de changement de management de projets informatique Page 66 / 79
Audrey LEPICOUCHE
2007
Ces documents, tels que les fiches de test, les documents dinstallation, etc. seront des documents dits applicables . Il existera galement dans cette procdure, des documents dit de rfrence qui seront le plan dassurance qualit, le planning, lanalyse des besoins Les documents applicables sont des documents qui permettent de dtailler de manire trs prcise les actions mener sur tel ou tel lment du projet. Les documents de rfrence sont des documents qui permettent dexpliquer de manire globale les actions mener pour le projet. Les documents de rfrences font appel aux documents applicables. Cette procdure devra galement signaler o se trouve les diffrents documents de rfrences et les documents applicables. De plus il devra galement y avoir dans ce document la liste et les contacts des diffrentes personnes lies au projet. Ainsi, seront prsents les contacts clients mais aussi les contacts des personnes rfrents du projet comme le chef de projet, le responsable qualit, le commercial, le responsable de compte Cette procdure sera accessible tous les membres de lquipe projet comme le chef de projet, les collaborateurs, les responsables hirarchiques et sera mis disposition de chacun par le biais de loutil de gestion des documents (GED).
6.5.1.3
Gestion et stockage de la documentation
La solution retenue, pour grer et stocker toute la documentation du projet, consiste mettre en place un outil de gestion lectronique des documents (GED). Cet outil permet de rfrencer de manire unique chaque document cr mais galement deffectuer un cycle de vie dun document, savoir la rdaction dun document, suivi par sa vrification, son approbation, sa publication et dans certains cas sa rvision. Ces diffrentes tapes sont faites laide dun workflow* incluant diffrents acteurs. Par exemple, un collaborateur rdige un document qui est ensuite vrifi par le responsable qualit, puis approuv et distribu par le chef de projet. Le document est la fin de cycle de cration dit applicable . Mais le cycle de vie du document nest pas termin, car le cycle de vie dun document se termine que lorsque le document est dit prim . Loutil GED permet de faire le cycle de vie dun 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 lintrieure du document doivent tre changes, il faut par le biais de loutil GED crer une nouvelle version du document. Cette nouvelle version permet dune part de lister les changements qui ont t faits dans le document et dautre part elle permet de commencer un nouveau cycle de vie pour le document. Ainsi le document en version 1 devient prim, une fois que la nouvelle version du document, soit la version 2 ou 1.1, est applicable.
Page 67 / 79
Audrey LEPICOUCHE
2007
Enfin grce au systme de workflow, loutil GED permet de faire un suivi sur les diffrents acteurs qui sont intervenus dans la vie dun document avec les dates et les heures prcises des modifications.
6.5.1.4
Les diffrentes runions
Concernant les diffrentes runions que le chef de projet doit organiser, il ny a pas rellement de dtails donner mis part le fait qu la fin de chaque runion, le chef de projet doit imprativement rdiger un compte-rendu de runion et le distribuer aux participants et aux ventuels acteurs cits durant la runion.
6.5.1.5
La communication par messagerie
Ds le commencement du projet et de la composition de lquipe projet, le chef de projet doit faire crer une messagerie lectronique commune tous les membres. La messagerie commune doit alors tre paramtre sur chacune des messageries des membres de lquipe projet afin quils puissent avoir accs aux messages mais aussi avoir accs au calendrier partag. Ladresse de cette messagerie doit tre communique au client afin que ce dernier puisse communiquer avec les membres de lquipe projet si besoin notamment pour des problmes techniques. Cette messagerie est gre essentiellement par le chef de projet, cest ce dernier qui met jour le calendrier. De plus, cest le chef de projet qui doit organiser de manire claire la messagerie en crant des dossiers en fonction des besoins. Il peut ainsi crer un dossier par module par exemple. Tous les messages envoys par un membre de lquipe projet concernant le projet doit se faire obligatoirement par la messagerie commune afin quil ny ait aucune perte dinformation. A linverse, toute communication externe concernant le dveloppement du projet doit arriver dans la messagerie commune afin que tous les membres de lquipe puissent en prendre connaissance. La messagerie commune permet galement de pouvoir grer des droits. Ainsi, le chef de projet peut demander ce que les diffrents membres de lquipe projet soit interdit de supprimer les messages prsents dans la messagerie commune. Le chef de projet peut galement, demander ce que les membres de lquipe ne puissent pas crer de nouveau dossier. Tout ceci permet au chef de projet de pouvoir grer seul la messagerie commune et ainsi de pouvoir en contrler son contenu et son organisation.
Page 68 / 79
Audrey LEPICOUCHE
2007

Concernant les aspects du management humain, deux points sont importants. Le premier point concerne essentiellement la composition de lquipe projet au commencement de celui-ci, le second point sattarde plus particulirement sur la planification du projet et notamment comment grer les aspects congs pays et les aspects de mise disposition du planning. Dans les solutions choisies voques prcdemment, il a t dcid de constituer lquipe projet de personnes multi-comptentes avec un pourcentage de remplaant dfini par le chef de projet. Pour dtailler, de manire plus prcise, la composition de lquipe est en fait base sur de la multi-comptence, autrement dit, le chef de projet ne recherche pas de personnes spcialis dun un seul domaine. Ainsi, dans un projet, il y a de multiples technologies qui sont utilises entre le systme dexploitation, le langage de programmation ou larchitecture, le matriel utilis par le client Il est donc important pour un projet, de trouver des personnes qui sont non seulement comptentes sur les technologies utilises durant le projet mais aussi sur des technologies susceptibles dtre utilises pour lavenir du projet. Ainsi les collaborateurs peuvent amener leurs comptences afin de pouvoir imaginer quel avenir peut avoir le projet et par consquent quelles est la manire la plus judicieuse de dvelopper le projet afin que celui-ci puisse vivre dans le temps. Par contre, le chef de projet nest pas dans lobligation de trouver des personnes ayant des comptences dans toutes les technologies utilises durant le projet. Ces personnes peuvent trs bien tre comptentes dans seulement deux ou trois technologies utilises. Il en va de mme pour les remplaants. Ces derniers doivent tre choisis de la mme manire que les membres titulaires . Concernant, la planification, le but est davoir toutes les informations ncessaires sur le planning du projet au commencement de celui-ci. Cest pour cela quil a t choisie comme solution que tous les membres de lquipe projet fournissent au chef de projet leurs dates de congs ds le commencement du projet ou la demande du chef de projet dans le cas de projet de longue dure. 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 cls du projet et par consquent de pouvoir faire le planning de pilotage qui sera prsenter 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 voques dans ce mmoire. Autrement dit, le planning interne sera mis disposition des collaborateurs par le biais du calendrier commun prsent sur la messagerie de chaque membre de lquipe. Le planning de pilotage sera mis disposition du client lors des comits de suivi organis par le chef de projet, puis sera enregistr dans loutil GED afin quil soit rfrenc et que le chef de projet puisse faire des versions de ce planning en fonction du droulement du projet.
Page 69 / 79
Audrey LEPICOUCHE
2007

Dans les paragraphes prcdents, deux solutions ont t retenues concernant lamlioration des conduites suivies lorsque des changements dans le management technique surviennent. La premire solution concerne la cration dune base de donnes qui permet de collecter toutes les informations sur les personnes faisant partie de la socit. Cette base de donnes sera une source unique de recherche de personnes et plus particulirement de comptences dans la socit. Cette base devra comporter les informations administratives et civiles de chaque employ, les informations sur le poste ou les postes occups dans la socit, des informations sur les comptences techniques et enfin cette base devra mentionne pour chaque employ sur quel projet ils ont travaill. Cette base de donnes devra par ailleurs tre accessible par tous les responsables dquipe de la socit et elle devra tre accessible par le biais dune interface graphique. Cette interface devra permettre chaque utilisateur de pouvoir faire des recherches par comptence, par poste, par nom, et par projet. De plus, cette base sera alimente uniquement par le service des ressources humaines, dans un premier lors de lembauche de chacun des employs et dans un second temps par demande de chaque responsable dquipe suite notamment aux formations que chaque employ a pu suivre. La seconde solution concerne la prparation dun basculement dune architecture une autre. Comme il a t expliqu auparavant, cette bascule se fera laide dun mode opratoire. Ce dernier, pour tre rdig, sera dcoup en plusieurs modules qui seront tous tests sparment les uns des autres. Aprs chaque test, une fiche de test est rdige. Une fois que chaque module aura t test et valid, le mode opratoire sera alors rdig en rassemblant chacun des modules les uns derrire les autres afin davoir le mode opratoire final. Le mode opratoire est alors test en son intgralit afin de sassurer quil ny a pas danomalie dans son droulement.

Dans ce paragraphe, va tre dtaille la solution concernant ltablissement dun document listant tous les pr-requis ncessaires pour rpondre une modification de primtre dun projet. Dans ce document, qui est prsent au client, apparat comme le primtre existant suivi du temps pass ou estim pour ce primtre. Par la suite est voqu le changement de primtre et ce quil comporte. Le chef de projet doit alors donner une estimation de la charge de travail pour prendre en compte ce nouveau primtre. Enfin, il apparat dans ce document, la date laquelle la modification pourra tre ralise et le cot financier. Ce document doit alors tre fourni au client pour quil le valide ou non.
Page 70 / 79
Audrey LEPICOUCHE
2007

Dans ce paragraphe, la manire de budgter un projet va tre voque. En effet dans les paragraphes prcdents, il a t voqu de choisir la solution dinclure dans le budget le financement concernant les risques lis au projet. La slection des remplaants des membres titulaires du projet fait partie de cette partie des risques et sera donc budgtis non pas dans le budget ncessaire au projet mais dans le budget des risques. Bien entendu, ces deux budgets sont assembls afin den faire quun seul qui sera prsent aux responsables hirarchiques du chef de projet. Chaque module est donc budgtis mais pour chacun deux le chef de projet va survaluer le budget afin davoir un budget plus large et ainsi pouvoir palier aux risques pouvant survenir dans nimporte quel domaine nimporte quel moment durant le projet.

Il a t voqu dans les paragraphes prcdents, quil est trs important que le chef de projet pense lavenir du projet afin de pouvoir garantir la dure de vie et la bonne qualit du projet. Dans les solutions voques 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 ncessaires pour savoir quel avenir ce projet pourrait avoir. Le chef de projet doit satteler obtenir ce type dinformation ds 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 dun 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 laider construire un avenir pour le projet.
Page 71 / 79
Audrey LEPICOUCHE
2007
7.
Processus de changement
A ce point du mmoire, les solutions, pour amliorer les conduites suivies face aux changements durant un projet informatique, ont t voques et expliques. Maintenant lobjectif est dexpliquer comment ces solutions vont tre mises en place afin quelles soient prises en compte le plus rapidement possibles Dans un premier, il sera expliqu par quel processus les solutions voques vont tre mise en place. Dans un second temps, il sera dtaill la mise en place de ces solutions et en dernier point seront voques les difficults qui ont t rencontres lors de la mise en place des solutions.
7.1
Description du processus
Le processus de changement est un processus simple mais trs long mettre en place car il demande un changement dhabitude des personnes concernes et ce genre de changement est dur et surtout long faire accepter puis mettre en place. Dans un premier temps, tous les changements voqus tout au long de ce mmoire doivent tre voqus et expliqus avec chaque employ de la socit qui est concern, de prs ou de loin, par ce changement. Cette mission de communication est donne chacun des responsables dquipe assiste par les personnes qui sont en charge de faire appliqu ces changements. Ainsi sur une priode plus ou moins longue, la communication sur le changement va se drouler. Le but est de prsent ces changements comme une volution positive de la vie de la socit. Ces changements doivent pouvoir aider chacun des employs dans leur travail, mais aussi doivent pouvoir amener de nouveau client et donc de meilleurs rsultats pour la socit, soit un meilleur intressement pour chacun des employs. Cette communication doit galement permettre chacun des employs de pouvoir participer ce changement et ainsi de pouvoir donner leur opinion et leurs ides pour mener bien ces changements. Une fois la communication passe dans toute la socit, le chantier peut alors commencer. Ce chantier est entirement mener par les diffrents chefs de projet en poste dans la socit car ceux sont eux les lments principaux du changement. En effet, les diffrents chefs de projet ainsi que leurs responsables doivent se runir 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 quils aient tous le mme langage et surtout tous la mme mthode. Ainsi, les collaborateurs nauront pas de soucis dadaptation lun ou lautre des chefs de projet. Ladaptation se fera quau dbut du chantier et si tout le monde parle le mme langage et utilise la mme mthode alors ladaptation se fera de manire trs rapide.
Page 72 / 79
Audrey LEPICOUCHE
2007
Une fois tous les documents ainsi que tous les outils comme la messagerie, loutil GED mis en place, lobjectif est qu chaque dbut de projet, les chefs de projet prsentent la nouvelle mthode et les diffrents outils chacun des membres. Les chefs de projet ont pour objectif de vrifier si la nouvelle est bien comprise et surtout si elle est bien utilise par tous les employs concerns.
7.2
Mise en place des amliorations
Comme il a t voqu dans le paragraphe prcdent, la cration des modles des diffrents documents de gestion de projet mettre en place est faite en collaboration avec tous les chefs de projet de la socit ainsi que leurs responsables. Ils ont pour objectif de mettre en vidence et par crit lutilit de chacun des documents et de leur donn une forme selon une charte graphique unique qui sera dfini par eux. Concernant la mise en place des outils, seul loutil GED est acqurir, installer et expliquer. En effet, cet outil une fois install devra tre expliqu tous les employs de la socit sous forme de formation. Il pourra y avoir deux types de formations, une premire concernant lutilisation gnrale de loutil, cest dire comment rechercher un document et comment le lire, et une seconde formation concernant lutilisation pousse de loutil, commente crer un document, le modifier, le supprimer En ce qui concerne la messagerie, la cration des diffrentes messageries communes se fera au fur et mesure de lacquisition de projet.
7.3
Difficults rencontres
Les difficults rencontres pour mettre en place ces changements sont surtout la raction des employs et plus particulirement la mauvaise volont de ces derniers. En effet, une minorit est toujours rfractaire au changement se qui ralenti le processus de changement. En effet, il est important pour la socit que tous les employs adhrent au changement. Par consquent, cela implique aux personnes charges du chantier, de trouver des arguments pour faire accepter ce changement mais aussi et surtout de rassurer continuellement les employs sur lavenir et le travail quils pourront faire avec ces changements. De plus, une autre difficult se situe au niveau du temps, en effet, il est important quune fois que ce changement est mis en place, quil soit adopt et utilis de manire rapide et sans accros. Pendant ce temps dadaptation, les personnes charges du chantier sont trs sollicites et ne peuvent pas rpondre tous les employs en mme temps. Ce qui provoque des tensions et par consquent des risques de rejet du changement. La difficult est donc de mettre beaucoup demploys de son ct afin daider les employs ayant des soucis suite aux changements. Enfin, il faut que les responsables soient beaucoup plus prsents afin de rassurer les employs mais aussi afin de les encourager.
Page 73 / 79
Audrey LEPICOUCHE
2007
8.
Synthse des rsultats et apport du travail
Ces changements sont des vnements trs bouleversants pour les employs, il est difficile de changer les habitudes des gens. Mais les changements mis en place sont des changements permettant de mieux grer les projets et ainsi perdre moins de temps et par consquent moins dargent. Le fait de rdiger toutes les informations circulant sur un projet permet tous de pouvoir suivre ou reprendre un projet sans trop de difficults. Par ailleurs, ces diffrents changements permettent chacun de bien comprendre quel est lenjeu mais aussi quelle est la plus-value de chacun dans un projet. Les collaborateurs se sentent entours et aids, 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 soccuper beaucoup plus de son client et tenter de lui proposer dautres prestations pour lesquelles il na pas souscrit. Tout ceci permet donc de finaliser des projets en temps et en heure et ainsi de pouvoir fidliser le client. Cela permet galement de pouvoir dcrocher de nouveau contrat et ainsi daugmenter le nombre de clients dans la socit. Ces changements amnent systmatiquement les employs changer leur mthode de travail, ainsi la gestion du temps de chaque employ est amliorer. Cela donne un nouveau souffle la socit et vite chacun de sancrer dans une routine qui peut engendrer une baisse de motivation pour chacun. Ces changements consacrs essentiellement aux projets informatiques peuvent galement tre mis en place pour dautres types de projets. Cela peut galement amener la socit revoir les diffrents processus qui sont actuellement en place dans la socit et qui demanderaient tre amliors. Tout le travail effectu pour mettre en place ces changements est bnfique puisquil permet chacun de pouvoir apprendre une nouvelle mthode de travail mais aussi et surtout de pouvoir unifier la faon de travailler dans toute lentreprise.
Page 74 / 79
Audrey LEPICOUCHE
2007
9.
Enseignements tirs
Les enseignements retirs de ce mmoire sont quil est difficile de faire accepter aux employs dune socit le changement. Il faut prendre au srieux les avis de chacun et surtout leurs sentiments et leur motivation. Les employs ont un fort pourcentage dans les risques puisquils ont le pouvoir de faire chouer un chantier dune telle ampleur. De plus, il est vident que ce genre de changement est long, trs long mettre en place. Cela demande beaucoup de patiente et beaucoup de rigueur. Le fruit dun tel travail ne peut pas sobserver au bout de quelques semaines mais plutt au bout de quelques mois voire au bout de quelques annes. Les autres enseignements qui peuvent tre tirs de ce mmoire sont que les diffrents changements qui peuvent survenir durant un projet ne peuvent pas tre lists puisque ces changements sont diffrents en fonction des projets. Or tous les projets sont diffrents puisquils sont uniques. Cest pour cela quil est important dtre organiser et davoir une bonne gestion de projet, cela permet de pouvoir faire face plus facilement des nouveaux changements qui bien entendus peuvent survenir nimporte quel moment du projet. De plus, dans ce mmoire, il parat 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 dun autre domaine et cest les relations entre ces diffrents domaines qui permettent de faire exister les projets. Cela implique, par consquent, que toutes les personnes travaillant sur un projet est essentiel, certes chaque personne peut tre remplace mais aucune delle ne peut tre enleve.
Page 75 / 79
Audrey LEPICOUCHE
2007
10.
Conclusions gnrales
Quelle est la conduite suivre sur le management du projet, lorsquun changement intervient durant un projet informatique ? Le mmoire commenait par cette question qui a enfin trouv une rponse ou plus exactement plusieurs rponses. Comme il a t voqu tout au long de ce mmoire, ce dernier donne des rponses sur des changements connus, mais les projets sont des vnements uniques, qui sont amens dcouvrir dautres changements qui demanderont alors tre tudis afin de trouver des solutions ces changements. Dans ce mmoire, le changement se gre plus facilement si le projet est correctement gr. En effet il ne faut pas que la gestion de projet soit un frein car tous les changements qui surviendront viendront sadditionner aux problmes et ne pourront donc pas tre rgls. Ce qui par consquent provoquera des abandons de projet et dans certains cas des pertes de contrats. Il est important de faire de la gestion des risques car cest cette gestion qui va permettre daller au devant des changements et par consquent de pouvoir y faire face sans difficults et sans risques pour le droulement du projet. Cette gestion des risques est llment 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 utilises dans dautres cadres que le projets informatiques, ces conduites peuvent tre utilises dans tous les types de projets car les domaines de management humain, technique, financier, commercial et le management de production sont des domaines prsents dans tous les types de projet et dans toutes les socits. Certes au niveau du management technique et du management de production certaines conduites vont sensiblement changes mais cela reste quand mme identique aux projets informatiques. Les nouvelles solutions mises en place dans ce mmoire vont maintenant permettre de pouvoir identifier de nouveaux changements et par consquent de pouvoir refaire tout le travail danalyse, de critique et damlioration sur ces nouveaux changements. Ainsi, de nouvelles solutions pourront tre trouves et pourront venir agrmenter les solutions de ce mmoire afin de renforcer les gestions de projet des socits.
Page 76 / 79
Audrey LEPICOUCHE
2007
11.
Bibliographie
Fernandez, Alain. Le chef de projet efficace 2e dition. Editions dorganisation, 2005. 168 pages. Ferrandon, Benot. Comprendre le management 1e dition. Edition Les cahiers franais, 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 Abrviations
AFITEP : Association francophone de management de projet AFNOR : Association franaise de normalisation TPE : Trs petite entreprise PAQ : Plan dassurance 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 dcrit le circuit de validation, les tches accomplir entre les diffrents acteurs d'un processus, les dlais, les modes de validation, et fournit chacun des acteurs les informations ncessaires pour la ralisation de sa tche
Page 77 / 79
Audrey LEPICOUCHE
2007
14.
Annexes
Rponses au questionnaire labor pour les interviews

Premier questionnaire 1. Quels sont les types de projets informatiques qui vous sont confis, dveloppement dapplications, mise en place darchitecture rseaux ? Je suis en charge de projets de dveloppement en tant que sous-traitant. Ceux sont des projets bass sur du Java J2EE ou du .NET 2. Les quipes projet sont composes de combien de collaborateurs en gnral ? Cela dpend de lampleur du projet, on tourne bien souvent par quipe de 5 personnes plus un chef de projet. 3. Quelle est votre dmarche actuelle pour grer les projets de type informatique ? Nous navons pas rellement de dmarche bien spcifique. La plupart du temps le chef de projet fait une runion dinitialisation avec le client pour discuter de ces besoins et par la suite, lquipe fait lanalyse des besoins puis le dveloppement. 4. Une fois que le projet a dbut, vous est-il dj arriv de faire face un changement inattendu ? Le plus souvent, le client rajoute des fonctionnalits dans son projet. On a parfois des collaborateurs qui changent. Sinon on na pas vraiment eu de gros changement. 5. Comment grez-vous des changements de types humains dans un projet informatique ? a. Changement du chef de projet ? Pas de rponse. b. Changement dun collaborateur ? Soit on fait appel un collaborateur qui est en inter-contrat et donc qui na pas de projet en cours, soit on embauche quelquun sur projet. c. Les arrts maladies ? Pour des courtes dures de moins dune semaine on ne fait rien sinon on prend une autre personne en attente de son retour. Comme pour avant cette personne peut tre en intercontrat. d. Les congs pays ? Les employs ont obligation de donner leurs congs pays avec un minimum trois semaines avant la date lorsquils sont sur un projet.
Page 78 / 79
Audrey LEPICOUCHE
2007
6. Au niveau technique, comment grez-vous les changements comme les modifications des besoins client impliquant bien souvent un changement de technologie (langage de programmation, architecture rseau ) ? Cela ne nous ait jamais arriv davoir ce genre de changement 7. Durant un projet, un chef de projet doit bien souvent rendre compte de son avancement auprs du client, quelle conduite avez-vous face au client lorsque vous devez lui annoncer un retard sur les dlais ? Prenez-vous alors un rle de commercial ? On prsente face au client les problmes rencontrs et le temps que ca prend pour rsoudre ces problmes, ensuite on leur annonce quil faudra dcaler la mise en production du produit. On essaie galement de leur montrer les solutions aux problmes que nous rencontrons si nous avons dj trouvs les solutions bien entendu. Nous ne faisons jamais de commercial, gnralement on prvient le commercial quand on sent quil y a des lments qui peuvent tre vendus au client 8. Comment grez-vous des changements au niveau financier dans un projet informatique ? a. Les restrictions budgtaires ? On fait avec les moyens quon nous donne mais on essaie de trouver les arguments ncessaires face nos responsables pour pouvoir garder notre budget dorigine b. Les formations imprvues, dues par exemple un changement de besoin client ? On essaie de les faire facturer au client dans le meilleur des cas, sinon cest nous qui finanons c. Rorganisation ou rachat de la socit, comment grez-vous la continuit du projet sans quil y ait dimpacte pour le client ? Pas de rponse 9. La mise en production marque bien souvent la fin dun projet, comment grez-vous un changement durant cette phase ? a. Le produit final est non fonctionnel dans lenvironnement client ? On essaie de rsoudre le problme dans lenvironnement client en laissant sur place un ou plusieurs collaborateurs en fonction des problmes b. Le client a chang un quipement dans son architecture remettant ainsi en dfaut le projet ? Idem que prcdemment
Page 79 / 79

La Conduite Du Changement

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

La Conduite Du Changement

Hochgeladen von

Copyright:

Verfügbare Formate

Nom : LEPICOUCHE Prnom : Audrey M2IRT 2007 TER

Rsum / Abstract et remerciements

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

Table des matires

1.1 1.2 1.3 2. 3.

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

REPONSES AU QUESTIONNAIRE ELABORE POUR LES INTERVIEWS ..................................................................... 78

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

4.1.1 Quest-ce quun projet informatique ?

La conduite de changement de management de projets informatique

4.1.2 Les types de management

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

4.1.3 Les types de changement

Les changements dans le management humain

Les changements dans le management technique

Les changements dans le management commercial

La conduite de changement de management de projets informatique

Les changements dans le management financier

Les changements dans le management de production

Audit / Diagnostic de lexistant

La conduite de changement de management de projets informatique

4.2.1 La conduite suivie lors dun changement humain

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

Les arrts maladie

Les congs pays

4.2.2 La conduite suivie lors dun changement technique

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

4.2.3 La conduite suivie lors dun changement commercial

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique

4.2.4 La conduite suivie lors dun changement financier

La conduite de changement de management de projets informatique

Rorganisation ou rachat de la socit

4.2.5 La conduite suivie lors dun changement en production

La conduite de changement de management de projets informatique

Produit final non fonctionnel

Architecture cliente modifie

4.3.1 La conduite suivie lors dun changement humain

Les arrts maladie

Les congs pays

4.3.2 La conduite suivie lors dun changement technique

Changement de langage de programmation

Changement darchitecture rseau

Changement de systme dexploitation

La conduite de changement de management de projets informatique

4.3.3 La conduite suivie lors dun changement commercial

4.3.4 La conduite suivie lors dun changement financier

La conduite de changement de management de projets informatique

4.3.5 La conduite suivie lors dun changement en production

Produit final non fonctionnel

La conduite de changement de management de projets informatique

Architecture cliente modifie

La conduite de changement de management de projets informatique

Mthodes et dmarches utilises

La conduite de changement de management de projets informatique

La conduite de changement de management de projets informatique