1.
Bienvenue dans notre formation
sur la Gestion de Projet
1
Philippe DORNBUSCH
Manager du service Projets RH et de la Mission Handicap à la
DRH du Crédit Agricole IDF
Fondateur de l’entreprise Echecs & Stratégie

2.
Le tour de table des participants à cette formation
2

3.
3
Tu me dis, j’oublie
Tu m’enseignes, je me souviens
Tu m’impliques, j’apprends
Benjamin Franklin, (1706-1790), écrivain, inventeur et homme politique américain
L’importance de la mise en pratique pendant cette formation

4.
Organisation pratique de cette journée
9h-9h30 Accueil des participants et tour de table
9h30 - 10h30 Définition de la gestion de projet
10h30 - 11h00 Pause
4
13h30 - 15h00 Règles pour éviter de faire déraper un projet
11h00 - 12h30 Les Outils clés pour bien gérer ses projets
12h30 - 13h30 Pause Déjeuner
15h00 - 15h30 Pause
15h30 - 16h30 Quiz individuel noté (10 questions)
16h30 - 17h00 Correction du Quiz et Conclusion de la journée

5.
Programme de la formation
C’est quoi la gestion de projet ?
Atelier fil rouge : les retours d’expérience en entreprise
Quelles sont les qualités d’un chef de projet ?
Comment entretenir la motivation des équipiers du projet ?
5
Quiz
Quiz
Comment éviter de faire déraper un projet ?
Quelles sont les règles de la relation avec le commanditaire ?

6.
Gestion de projet 6
Introduction
Nous ne tomberons pas non plus dans l'extrême chère à Jules Romain, décrétant que
« tout bien portant est un malade qui s'ignore ».
Nous allons passer en revue au cours de cette formation un certain nombre de
points qui s'ils se vérifient ou si ils sont absents, constitueront pour vous autant de
sonnettes d'alarme.
Il est plus difficile de décrire comment on
mène bien un projet que de décrire comment
on peut le rater. De plus il est plus aisé de
détecter un dérapage que de vérifier que tout
va bien. Nous procéderons donc par
élimination, un peu comme dans le secteur
médical où est déclaré "en bonne santé" tout
individu ne présentant pas de symptôme
notoire d'une pathologie connue.

7.
Gestion de projet 7
Introduction
Quelles sont les compétences attendues d'un bon chef de projet ?
Au-delà des compétences techniques attachées au livrable d’un projet, un ensemble de
compétences relationnelles et comportementale est nécessaire au chef de projet pour
obtenir le meilleur des équipes engagées :
• Capacité à interagir avec les autres, en fonctionnement transversal, dans la diversité
des cultures d’entreprises, des cultures internationales, en pleine conscience de
ses responsabilités,
• Etre en paix avec soi-même, pour savoir porter des jugements impartiaux, résoudre
des conflits sans a priori, et apparaître digne de confiance.

8.
Gestion de projet 8
Introduction
La gestion de projet est fondée sur le découpage des différentes tâches à effectuer en
étapes. Ces étapes sont :
 schéma directeur,
 étude préalable,
 étude détaillée,
 étude technique,
 et production des logiciels.
La gestion de projet va consister à l'organisation de ces différentes étapes et au suivi du
bon déroulement de ces étapes.
 Comment planifier les travaux ?
 Comment maintenir la motivation des équipiers sur toute la durée du projet ?
 Comment éviter de faire déraper un projet ?
 Quels sont les quelques bons outils à utiliser ?
 Et enfin, comment clore un projet pour en tirer le meilleur profit ?
Ce sont les objectifs de cette formation à la gestion de projet.

9.
Gestion de projet 9
Introduction : C’est quoi la gestion de projet ?
La gestion de projet en 2 min : https://www.youtube.com/watch?v=KstwnJm4OO0

10.
 Un projet est un ensemble de tâches
indissociables permettant de
répondre à des besoins
 Il comprend également les
ressources nécessaires à sa
réalisation
 Il a une durée finie, caractérisée par
une date de début et une date de fin
 Il peut être multi technique, mono
technique, collectif ou individuel
Gestion de projet 10
Introduction : définition ISO 10 006 d’un projet
« Processus unique, qui consiste en un ensemble d'activités coordonnées et maîtrisées
comportant des dates de début et de fin, entreprises dans le but d'atteindre un objectif
conforme à des exigences spécifiques telles que des contraintes de délais, de coûts et
de ressources » [ISO 10006, 1997]

11.
Les caractéristiques d'un projet
La caractéristique d'un projet est d'avoir un début et une fin :
Vrai ou Faux ?
Gestion de projet 11
Parmi les adjectifs suivants, lesquels peuvent caractériser le
résultat d'un projet :
Immatériel, matériel, unique, mesurable, quantifié, flou, national, régional.
Parmi les expressions suivantes, identifier celles qui ne
s'appliquent jamais à un projet :
Structuré, permanent, répétitif, innovant, transverse, temporaire.

12.
 Tournée vers l'atteinte d'un objectif clair et quantifié
 Non répétitive (Mise en place d'une structure temporaire)
 Réactive
 Aléas de la réalisation, ré arbitrages...
 Modification du cahier des charges, évolution de l'environnement...
 Personnalisée par un chef de projet ayant une obligation de
résultat
 Soumise à des contraintes (Délai, Coût, Qualité)
Gestion de projet 12
Introduction : les caractéristiques de la conduite de projet

13.
13
Un projet est basé sur 4 éléments.
Lesquels, selon vous ?
Gestion de projet

14.
Des acteurs
Responsable Projet,
contributeurs…
Des bonnes
pratiques
Des étapes
Cadrage, conception,
bilan…
Trois
contraintes
14Gestion de projet
Introduction : Un projet est basé sur 4 éléments

15.
C’est quoi un projet ? Une autre définition plus simple
Projet = opération ponctuelle ayant un début et une fin, nécessitant la
mise en œuvre de ressources humaines et matérielles pour sa réalisation.
15Gestion de projet

16.
C’est quoi la gestion de projet ? Objectif
La gestion de projet est fondée sur le découpage des différentes tâches à
effectuer en étapes. Ces étapes sont :
- schéma directeur,
- étude préalable,
- étude détaillée,
- étude technique,
- production des logiciels.
La gestion de projet va consister à l'organisation de ces différentes
étapes et au suivi du bon déroulement de ces étapes.
Chaque étape peut se découper en trois périodes. A chaque période, un
certain nombres d'opérations sont indispensables pour une bonne
exécution de l'ensemble.
16Gestion de projet

17.
C’est quoi la gestion de projet ?
Au moment du lancement d'une étape il faut :
- composer la ou les équipes qui conduisent les travaux,
- planifier les travaux et l'affectation des ressources,
- mettre en place les structures de décision qui approuveront les travaux (en
phase de conception) ou qui réceptionneront les programmes (en phase de
réalisation).
Pendant le déroulement d'une étape il faut :
- faire un compte rendu d'activité et mettre à jour le planning,
- faire un suivi des travaux : analyser les écarts de planning, moduler l'attribution
des ressources,
- procéder au suivi de la documentation :
. comptes rendus de réunions;
. formalisation des modèles;
. notes de synthèse ...;
- contrôler la conformité des spécifications par rapport aux options prises
pendant la ou les précédentes étapes.
17Gestion de projet

18.
C’est quoi la gestion de projet ?
À la fin d'une étape il faut :
- approuver ou réceptionner les travaux,
- contrôler les travaux par rapport aux normes d'assurance qualité,
- évaluer les travaux à conduire pour l'étape suivante et réactualiser éventuellement
les charges pour les étapes situées au-delà de l'étape suivante.
L'expérience a démontré que de nombreuses erreurs liées à l'insuffisance de
préparation et de planification des travaux nécessaires à la réalisation étaient
commises au démarrage d'une étape. À titre d'exemple ces erreurs peuvent être :
- celles liées à la non exhaustivité des spécifications concernant les objectifs,
- celles liées à l'absence de plan de réalisation des spécifications ou du logiciel,
- celles liées à la mise à disposition des moyens nécessaires.
La préparation et le lancement d'une étape consistera à définir précisément les
quatre types de ressources nécessaires à sa réalisation qui sont d'ordre
méthodologique, humain, logiciel et logistique.
18Gestion de projet

19.
C’est quoi la gestion de projet ?
En fonction du type de projet, de sa taille et de sa complexité, on précisera comment
sera utilisé la méthode en expliquant les adaptations éventuelles portant sur :
- la définition affinée de la méthode,
- la définition de la documentation à utiliser,
- la définition de la procédure de pilotage du projet
- la définition de la méthode d'approbation ou de réception des résultats de l'étape.
En ce qui concerne les ressources humaines il faudra préciser :
- au niveau interne :
. profil nécessaire;
. description des fiches de poste :
* compétences,
* niveau,
* connaissances indispensables,
* motivation,
* nombre de personnes et taux de disponibilité,
* qualification,
. organigramme hiérarchique du projet .
19Gestion de projet

20.
C’est quoi la gestion de projet ?
- au niveau externe :
. profil des personnes qui seront en contact avec l'équipe projet;
. hiérarchie souhaitée;
. pouvoir réel de décision.
Au niveau logiciel il faudra préciser quels seront les logiciels et outils nécessaires à :
- la gestion de la documentation,
- la planification et le suivi du projet,
- le développement du projet,
- etc ...
20Gestion de projet

21.
C’est quoi la gestion de projet ?
Pour ce qui est de la logistique il sera indispensable soit de prévoir la fourniture ou la
gestion :
 des commodités et des communications comme :
- bureaux,
- téléphone,
- parking,
- horaires d'accès ou de moyens de transport,
- de la disponibilité de l'outil informatique :
. modalités de login,
. modes d'utilisation,
. sauvegardes préalables, ...
- du secrétariat,
- photocopies, ...
21Gestion de projet

22.
Planification des travaux
Le planning est élaboré par le chef de projet. Celui-ci recense les différentes tâches à
exécuter et précise les attributs les définissant. Pour ce faire, chaque tâche est elle
même découpée en opérations car ne pas tenir compte de chaque élément, grain de
sable au milieu de l'ensemble, pourrait justement devenir le grain de sable bloquant le
dit ensemble.
Une opération élémentaire est définie par :
- l'identification de l'opération,
- l'identification de la tâche auquel elle se rapporte,
- l'identification du personnel devant réaliser l'opération,
- l'identification du résultat attendu de l'opération,
- l'identification du groupe devant la valider,
- la durée prévue,
- la date de début prévue,
- la date de fin prévue,
- la durée réelle,
- la date de début réelle,
- la date de fin réelle,
- l'état de l'opération (Attente de démarrage, en Chantier, Terminée, Validée).
22Gestion de projet

23.
C’est Planification des travaux
Les mêmes critères peuvent être retenus pour définir une tâche.
Le chef de domaine effectue le même travail de planification que le chef de projet mais
au niveau des étapes et du domaine.
Le chef de produit effectue le même travail de planification que le chef de domaine
mais au niveau du projet qui est une version du produit.
Il est à noter qu'un tel découpage et qu'une telle hiérarchie ne sont nécessaires que
pour de très grands projets. Dans la pratique quotidienne en milieu mini informatique
c'est rarement le cas.
23Gestion de projet

24.
Quelles sont les qualités requises du chef de projet ?
24

25.
Gestion de projet 25
Les compétences du chef de projet : une rose des vents !

26.
Gestion de projet 26
Les compétences du chef de projet : une rose des vents !
Au-delà des compétences techniques attachées au
livrable d’un projet, un ensemble de compétences
relationnelles et comportementale est nécessaire pour
obtenir le meilleur des équipes engagées :
• Capacité à interagir avec les autres, en
fonctionnement transversal, dans la diversité des
cultures d’entreprises, des cultures internationales,
en pleine conscience de ses responsabilités,
• Etre en paix avec soi-même, pour savoir porter des
jugements impartiaux, résoudre des conflits sans a
priori, et apparaître digne de confiance.

27.
Gestion de projet 27
Les compétences du chef de projet : une rose des vents !
Pourquoi l’utiliser ?
Objectif
 Permettre au chef de projet de prendre conscience de toutes les facette de son
rôle, d’identifier ses forces et ses points d’amélioration. C’est un bon moyen pour
le chef de projet de doper sa confiance en lui… et son humilité !
 Eclairer le chef de projet sur les attentes de son équipe vis-à-vis de lui. Une équipe
projet n’attend pas un simple savoir-faire d’organisation et de planification, mais
aussi du soutien, de la facilitation dans les situations transversales,
multiculturelles, et de la flexibilité face aux situations rencontrées.
Contexte
L’évaluation des compétences du chef de projet doit se faire régulièrement (a minima
à un rythme annuel), de façon à mesurer les talents qui ont été acquis lors des
derniers projets, et ceux qui restent à développer.

28.
Gestion de projet 28
Les compétences du chef de projet : une rose des vents !
Comment l’utiliser ?
Etapes
 Faire le tour d’horizon de sa propre perception de son niveau de maîtrise sur
chacune des compétences listées.
 Demander à son environnement professionnel (acteur du projet, hiérarchiques,
autres chefs de projet) ce qu’il s pensent de la maîtrise des compétences listées,
en considérant ce qu’ils sont capables d’apprécier de leur activité.
 Recouper ces informations avec ses propres perceptions et construire un plan de
progrès :
 Lister les actions de formation, de séances d’accompagnement avec des chefs de
projets expérimentés, ou toute autre action admise par l’organisation,
 Prioriser ces actions avec son responsable hiérarchique,
 Planifier les actions prioritaires à mettre en œuvre,
 Organiser un feedback avec son responsable hiérarchique pour valider l’atteinte
des objectifs fixés.

29.
Gestion de projet 29
Les compétences du chef de projet : une rose des vents !
Comment l’utiliser ?
Méthodologie et conseils
 La description des compétences du chef de projet est souvent un sujet de
polémique. En premier lieu, le chef de projet doit-il maîtriser les expertises
techniques de son projet ? Il n’y a pas de réponse universelle à cette question.
Dans les petits projets, le chef de projet maîtrise aussi la technique, car il exécute,
pour le compte du projet, des travaux de réalisation. Dans les grands projets,
toute son activité est focalisée dans le management des travaux et des équipes. Il
n’a pas à être expert sur les techniques de son projet. Par contre, sa capacité à
comprendre les experts, à apprécier la solidité de leur point de vue est
fondamentale. Il est alors « expert en conséquence », pour le compte du projet

30.
Gestion de projet 30
Les compétences du chef de projet : une rose des vents !
Avantages Précaution à prendre
• La cartographe des
compétences permet au chef
de projet d’élargir la
compréhension de son rôle.
• Elle lui permet d’identifier les
points sur lesquels il doit
progresser
• Elle lui donne les moyens
d’obtenir la perception des
acteurs dans son
environnement (démarche
proche de 360] feedback)
• Les compétences listées sont
souvent difficiles à apprécier. Et
chacun les apprécie à sa manière.
Il est donc important de chercher
systématiquement à identifier les
faits significatifs illustrant les
compétences revendiquées.

31.
Un animateur
– Il fédère l'équipe projet
Un communicateur
– Il est en mesure à tous les
stades d'informer le comité de
pilotage
– Il informe également ses
partenaires
Un responsable
– Il dispose de moyens et
d'obligations
– Il doit tenir ses objectifs
Il ne porte pas tout sur
ses épaules...
Gestion de projet 31
Les acteurs : le chef de projet

32.
Les missions du Chef de projet
 Définition du projet
 Planification du projet
 Pilotage du projet
 Négociations internes et externes au projet
 Animation des équipes
 Reporting interne et externe
 Gestion du fonds documentaire
Gestion de projet 32
Les acteurs : le chef de projet

33.
Le plan de communication du projet
33

34.
Gestion de projet 34
La communication, première compétence du chef de projet
Le lien vers la vidéo

35.
Gestion de projet 35
Le plan de communication du projet
Certains projets impliquent de nombreux acteurs et
services, et il est recommandé d’établir un plan de
communication en début de projet, pour permettre à
chacun d’accéder à l’information dont il a besoin.
Ce plan de communication intègre :
• L’identification des destinataires de l’information,
• Une description de l’information à diffuser (rapports
d’avancement, données, calendrier, documentation
technique, etc.)
• Les méthodes utilisées pour diffuser les divers types
d’information,
• Les fréquences pu dates qui précisent à quel moment
chaque type d’information est transmis.

36.
Gestion de projet 36
Le plan de communication du projet
Pourquoi l’utiliser ?
Objectif
 Informer l’ensemble des parties prenantes concernées par le projet ou qui en
subissent un impact.
 Organiser les actions de communication, en déduire la charge de travail induite, et
l’intégrer dans les activités du projet, pour garantir qu’elles seront bien réalisées.
Contexte
Le plan de communication est conçu une fois que le chef de projet a réalisé un
premier cadrage du projet, de ses impacts, et de l’ensemble des parties prenantes qui
vont être touchées.
Il peut être élaboré en relation avec la direction de la communication de l’entreprise,
pour profiter du savoir-faire, et pour en faciliter l’exécution grâce à un soutien plus
fort.

37.
Gestion de projet 37
Le plan de communication du projet
Comment l’utiliser ?
Etapes
1. Identifier l’ensemble des parties prenantes du projet.
2. Segmenter ces parties prenantes en différents groupes cibles.
3. Déterminer les types de messages que l’on souhaite diffuser à chaque groupe
cible.
4. Sélectionner les moyens de communication compatibles avec la culture
d’entreprise.
5. Etablir un budget prévisionnel de communication à intégrer au budget du projet.
6. Mettre en place un processus de contrôle afin d’évaluer l’efficacité du plan de
communication à tout moment.

38.
Gestion de projet 38
Le plan de communication du projet
Comment l’utiliser ?
Méthodologie et conseils
Vérifier la robustesse du plan de communication en répondant aux questions
suivantes :
 Toutes les cibles ont-elles été prises en compte ?
 Chaque action de communication a-t-elle été affectée à un acteur du projet ?
 Le plan de communication prévoit-il un dispositif de recueil et de traitement des
réactions sur le projet ?
 Comment la direction est-elle impliquée dans le plan de communication ?
 Le client a-t-il validé le plan de communication ?
 Le plan de communication contient-il un planning des actions de communication ?
 Le plan de communication est-il cohérent avec les grands jalon du projet ?

39.
Gestion de projet 39
Le plan de communication du projet
Avantages Précaution à prendre
• La mise en place d’une
communication régulière réduit
les risques de rumeurs et de
peurs associées au projet.
• La transparence favorise
l’acceptation du changement
généré par le projet.
• Utilisez des support de
communication simples.
• Etre à l’écoute es réactions de
chacun.
• Communiquer plutôt largement,
sans pour autant noyer les gens
sous l’information.
• Favoriser l’explication et la
disponibilité de l’information.

40.
Comment entretenir la motivation des équipiers du projet ?
40

41.
Gestion de projet 41
La motivation des équipiers du projet
La motivation de chaque équipier ne se décrète pas, elle se construit. Au
travers de sa fameuse pyramide, Abraham Maslow a exprimé que les
besoins humains sont dynamiquement fluides - avec plusieurs de ces
besoins présents dans une personne simultanément. Transposés à l’univers
des projets, ces 5 niveaux de besoins donnent des pistes concrètes au chef
de projet pour mettre en place les conditions de motivation de son équipe
Le lien vers la vidéo sur les émotions de l’équipier
Comment prendre en compte les émotions de l’équipe dans le management du projet

42.
Gestion de projet 42
Le tableau de clés de motivation du projet
Leviers de motivation
(source Maslow)
Exemples
Fait dans mon
projet ?
Qui dans l'équipe est
sensible à ce levier ?
Proposer des tâches qui permettent aux collaborateurs de devenir des experts
Faire réaliser un ensemble plutôt qu'une partie, c'est donner à l'individu une unité
naturelle et complète de travail
Introduire des tâches nouvelles et des tâches plus difficiles
Faire des rapports périodiques à l'équipier, reconnaître ses résultats ou efforts
Accorder plus de liberté à l'équipier dans la manière d'accomplir son travail
Retirer certains mécanismes de contrôle sans détruire les possibilités de
vérification, voire permettre des autocontrôles par l'équipier lui-même
Permettre à l'équipier de présenter son travail au comité de pilotage, et de se faire
connaître
Tenir le hiérarchique de l'équipier informé des résultats
Prendre le temps de rencontrer l'équipier et de définir son rôle dans l'équipe
Organiser une réunion de lancement avec un moment de convivialité
Organiser des réunions d'avancement rituelles, avec des pratiques propres à
l'équipe projet.
Favoriser les moments informels : machine à café, repas collectifs, etc.
Montrer l'implication du commanditaire du projet pour prouver que le projet n'est
pas "vain" et qu'il ne va pas s'arrêter en cours de route
Donner un cadre précis par rapport à la réalisation de la tâche
Utiliser des outils de pilotage qui rassurent
Garantir les moyens, la disponibilité nécessaire pour réaliser la tâche
Faire attention à ce que la fréquence et les horaires des réunions d'avancement
respectent le rythme personnel/professionnel de l'équipier
Qualité de vie
professionnelle
Dépassement de soi
Besoin de reconnaissance
Besoin d'échanges, de
communication,
d'appartenance à un groupe
Elimination de l'incertitude

43.
Gestion de projet 43
Le tableau de clés de motivation du projet
Pourquoi l’utiliser ?
Objectif
 Trouver les clés pour motiver et obtenir l’engagement des équipier du projet.
 Identifier ce qui peut démotiver les équipier et trouver les antidotes.
Contexte
La motivation des équipiers du projet est valable pour tous les types de projets, et
doit se faire le plus en amont possible de la collaboration. Sur les projets longs, les
leviers de motivation peuvent évoluer dans le temps.
Avantages Précaution à prendre
Prendre conscience que
chaque équipier est différent
et sera motivé par des leviers
différents dans le projet
Parfois, le chef de projet n’a pas
les clés pour motiver certains
collaborateurs. Pas d’acharnement
thérapeutique ! La motivation n’est
pas une fin en soi

44.
Gestion de projet 44
Le tableau de clés de motivation du projet
Comment l’utiliser ?
Etapes
 Compléter le tableau « les clés de motivation de mon projet » pour identifier les
pistes propres au projet, et éventuellement celles qui ne sont pas activables dans
le projet
 Identifier les leviers sur lesquels vous allez vous appuyer collectivement, dans le
cadre des actions de communication et des réunions.
 Dans le cadre des entretiens de délégation, prendre le temps de demander à
l’équipier quelles sont ses attentes par rapport au projet, et identifier la manière
dont vous allez répondre à ses attentes.
 Compléter le tableau en associant le nom des équipiers aux leviers qui les
motivent, et vérifier régulièrement que vous les « nourrissez » sur ces leviers.
 Prendre la température régulièrement , dans un cadre individuel

45.
Gestion de projet 45
Le tableau de clés de motivation du projet
Comment l’utiliser ?
Méthodologie et conseils
 Ce n’est pas dans une grande réunion d’équipe que vous allez découvrir ce qui
motive l’équipier : prenez le temps de le rencontrer dans un cadre individuel, et
de lui consacrer le temps dont il a besoin. C’est un investissement pour l’avenir !
 L’équipier ne sait pas forcément ce qui le motive ! Demandez-lui ce qui lui a plu et
déplu dans les projets précédents. Il ne sait pas forcément ce qui le motive dans
un projet, mais saura vous dire ce qui le démotive.
 Attention à la projection : nous projetons sur les équipiers du projet nos propres
leviers de motivation. Cela a des conséquences positives (nous avons le « feu
sacré » sur ces leviers) mais aussi négatives (il n’est pas sûr que ce soit le meilleur
levier pour motiver l’équipier, et cela peut même l’inquiéter : par exemple, je
vends du challenge à quelqu’un qui veut de la sécurité). Ecoutez, écoutez, écoutez
avant de chercher à motiver.

46.
Gestion de projet 46
Le tableau de clés de motivation du projet
Comment l’utiliser ?
Méthodologie et conseils
 Avant de « vendre » le projet, garantir le minimum de base. En effet, nous avons
souvent envie de présenter les aspects attrayants du projet (haut de la pyramide
de Maslow) avant d’avoir garanti le bas de la pyramide à l’équipier. Préparez bien
la fixation de l’objectif de l’équipier, afin de réduire l’incertitude associée à sa
tâche et de le sécuriser.
 Trop ou pas assez de contrôle tue la motivation. Rien de pire que d’imposer un
compte-rendu quotidien à un expert, ou au contraire de laisser un débutant
travailler un mois sans point de contrôle. Adoptez une posture de « chef de projet
coach », et définissez avec votre interlocuteur le niveau de contrôle adapté, plutôt
que de lui imposer.

47.
Quelles sont les règles de la relation avec le commanditaire ?
47

48.
Gestion de projet 48
Les règles de la relation avec le commanditaire
Dès le démarrage, établir
une relation avec le
commanditaire/équipe
projet.
Intégrer le commanditaire
dans les travaux pour
« entrer dans sa bulle » et
le faire adhérer à la
solution
Etre exigent avec le
commanditaire en termes
de qualité des informations
transmises, prises de
décision, influence en
interne.
Veiller à la bonne impression
que le projet laisse au final
au commanditaire
Initialisation Cadrage/préparation Réalisation Transfert/clôture
Degré d’engagement
du commanditaire
Phases
du projet

49.
Gestion de projet 49
Les règles de la relation avec le commanditaire
Le lien vers la vidéo transmettre sa vision du commanditaire à l’équipe projet

50.
Gestion de projet 50
Les règles de la relation avec le commanditaire
Le commanditaire est le donneur d’ordre du projet.
Le chef de projet doit lui accorder une attention particulière sur 4 dimensions :
 Etablissement et maintien d’une relation de travail étroite, pouvant aller
jusqu’à la coproduction sur le projet, et imposant une connaissance la plus
précise possible de la personne
 Utilisation de ses leviers de pouvoir pour gagner du temps ou de l’énergie
 Implication dans ses actions de validation
 Communication vers le commanditaire et vers l’organisation, pour s’assurer
de la convergence de travaux vers l’objectif réel de l’organisation, et pour
valoriser le commanditaire.
Le chef de projet doit avoir en permanence l’objectif de se faire du
commanditaire un allié.

51.
Gestion de projet 51
Les règles de la relation avec le commanditaire
Pourquoi l’utiliser ?
Objectif
 Etablir la relation projet/commanditaire et maintenir cette relation.
 Assister le commanditaire dans l’élaboration du besoin et dans la validation des
résultats.
 Contribuer positivement à l’image du commanditaire dans l’organisation.
 Garantir l’alignement du projet sur les objectifs du commanditaire.
 Obtenir du soutien lorsque c’est nécessaire.
Contexte
Le commanditaire est le client. Il est à l’origine du projet. Le chef de projet est
nommé postérieurement à l’apparition du commanditaire dans le paysage du projet.
Il doit donc réussir à créer la relation, telle qu’il le souhaite, pour gagner en efficacité
sur le projet. Il est bien de son ressort de « reprendre la main » sur le projet, et donc
de conduire la relation avec le commanditaire, sans se laisser conduire. Il lui est
cependant nécessaire de continuer de l’écouter, de prendre en compte ses
recommandations et ses besoins; C’est cet équilibre que les règles aident à établir.

52.
Gestion de projet 52
Les règles de la relation avec le commanditaire
Comment l’utiliser ?
Etapes
 Dès le démarrage, établir l relation commanditaire/équipe projet :
 Intégrer le commanditaire dans le trombinoscope du projet, annuaire du projet,
 Définir les modes de fonctionnement, les rôles et les responsabilité de chacun
 Identifier les enjeux personnels du commanditaire : sécuriser le projet, être
valorisé et flatté par le projet, être surpris par le projet, disposer d’un résultat
pratique, préserver la dimension financière, valoriser l’image de marque de
l’entreprise.
 Intégrer le commanditaire dans les travaux pour « rentrer dans sa bulle »
 Définir les temps de rencontre physique avec le commanditaire,
 Co-construire le projet avec le commanditaire : l’aider à formaliser et à
hiérarchiser son besoin,
 Faire réagir le commanditaire sur des exemples de solutions

53.
Gestion de projet 53
Les règles de la relation avec le commanditaire
Comment l’utiliser ?
Etapes
 Etre exigent avec le commanditaire dans la phase de réalisation. Oser lui
demander de :
 hiérarchiser ses demandes,
 Informer le chef de projet de toutes les décision et orientations prises,
 S’impliquer dans la réunion de lancement du projet,
 Faire du « lobbying » en faveur du projet lorsque c’est nécessaire.
 Veiller à l’impression que le projet laisse au final au commanditaire :
 Montrer l’atteinte des objectifs
 Montrer le sentiment partagé au sein de l’organisation que le déroulement a été
harmonieux et efficace

54.
Gestion de projet 54
Les règles de la relation avec le commanditaire
Comment l’utiliser ?
Méthodologie et conseils
La mise en œuvre de ces règles relève autant d’outils et de méthodes que du
comportement approprié du chef de projet. Un chef de projet débutant, de même
qu’un chef de projet trop technique pourra rencontrer des difficultés dans le mise en
pratique de ces règles.
Avantages Précaution à prendre
La formalisation de ces règles
vise à considérer le
commanditaire sous toutes ses
facette : donneur d’ordre donc
décideur, mais aussi acteur
contributeur, et acteur influent
Le niveau d’exigences que le chef de
projet souhaite mettre en place dans la
relation (fréquence des rencontres,
précisions des informations fournies,
etc.) doit être compatible avec ce que
le commanditaire est prêt à supporter,
sur le durée du projet.

55.
Le tableau de bord du projet
55

56.
Gestion de projet 56
Le tableau de bord du projet
Le lien vers la vidéo

57.
Gestion de projet 57
Le tableau de bord du projet
Il donne une vision synthétique de l’état de santé du projet : valeur réelle par
rapport aux valeurs prévues, tendances.
Il affiche les fait marquant de la période, selon le chef de projet et l’équipe projet.
Il aide les donneurs d’ordre dans leur prise de décision.
Le tableau de bord de projet présente,
en un nombre de pages restreint, de
manière principalement graphique, les
indicateurs clés du projet
(performance, coûts, délais et risques).

58.
Comment éviter de faire déraper un projet ?
58

59.
Comment éviter de faire déraper un projet ?
Il est plus difficile de décrire comment on mène bien un
projet que de décrire comment on peut le rater. De plus il
est plus aisé de détecter un dérapage que de vérifier que
tout va bien. Nous procéderons donc par élimination, un
peu comme dans le secteur médical où est déclaré "en
bonne santé" tout individu ne présentant pas de
symptôme notoire d'une pathologie connue.
Nous ne tomberons pas non plus dans l'extrême chère à
Jules Romain, décrétant que tout bien portant est un
malade qui s'ignore.
Nous allons donc passer en revue un certain nombre de
points qui s'ils se vérifient ou si ils sont absents,
constitueront pour vous autant de sonnettes d'alarme.
59Gestion de projet

60.
Comment éviter de faire déraper un projet
Quelles sont les composantes d'un projet informatique?
1) L'homme
- décideur,
- client,
- réalisateur.
2) Les méthodes
- conception,
- analyse,
- développement.
3) Les techniques
- matériels,
- logiciels.
L'homme est certainement la cause principale d'échecs d'informatisations. Gérer et
développer des produits informatiques revient à gérer des hommes.
Principalement mais pas uniquement, la pratique des méthodes est aussi un gage de
succès, de même qu'une base minimum de connaissances en informatique. 60

61.
Causes et situations d'échecs, possibles
Nous allons passer en revue un certain nombre de causes ou de situations à éviter ou
de solutions à préserver, voire à mettre en place pour tenter d'éviter un échec. Il est
impératif de garder à l'esprit que tous les points qui vont suivre ne regardent pas
forcément l'informaticien et que ce n'est pas forcément à l'informaticien ou au
programmeur de base de les prendre en charge ni de donner un avis dessus.
Si ils sont développés ici ce n'est que pour donner une vue d'ensemble sur la gestion
d'un projet.
61
Définir les besoins
Quel n'est pas le client qui
exprime vaguement un besoin,
qui doit être bien entendu très
rapidement réalisé, alors qu'il ne
sait même pas lui même ou à
peine, ce qu'il doit contenir ?

62.
Causes et situations d'échecs, possibles
Faire accoucher le demandeur
Le demandeur n'est généralement pas informaticien. Il est persuadé que sa demande
est cohérente. Et elle l'est en fonction des possibilités techniques dont il a
connaissance initialement ou de la méthode de travail utilisée à ce jour.
Il appartient alors au réalisateur d'aider le client à reformuler sa demande dans un
autre langage ou sous une autre forme.
Le cas typique, est ce client demandant la fourniture d'un listing des factures dues par
débiteur.
Sans question supplémentaire, le réalisateur se mettrait au travail immédiatement et
fournirait la satisfaction du besoin exprimé.
Si d'aventure le réalisateur pousse plus loin ses investigations et demande à quoi va
servir ce listing, il va découvrir que lors d'une saisie de règlement l'opérateur à besoin
de connaître les nos des factures dues pour imputer ce règlement.
62

63.
Causes et situations d'échecs, possibles
Faire accoucher le demandeur
Le réalisateur pourra alors livrer une liste écran avec choix sans re-saisie du no de
facture ce qui satisfera le véritable besoin de l'utilisateur.
L'analyse vise à retranscrire les éléments du cahier des charges, qui est généralement
incomplet, car le besoin brut exprimé devra être affiné lorsque le client verra plus clair
dans les solutions techniques qui lui sont proposées.
Le maximum de points laissés sans réponses doit être confirmé et éclairci avant de
débuter les travaux ou doivent être formalisés puis suivis plus particulièrement car ce
sont eux qui engendreront les écarts sur le résultat final.
63

64.
Causes et situations d'échecs, possibles
Définir la stratégie informatique
Un besoin même si il est traité isolément, est et restera rarement unique. Il s'inscrit
généralement dans un système plus vaste même si la finalité de ce système est
éloignée dans le temps.
Il est donc indispensable de définir les grands axes du développement informatique
général, non limités à la réalisation initiale, sous peine de devoir ultérieurement
modifier les fondations de l'ouvrage. La difficulté en la matière est d'appréhender ce
qui n'est pas encore exprimé.
Ce besoin de posséder le plus rapidement possible la nature de la stratégie
informatique à long ou moyen terme par rapport à l'automatisation en cours, est
encore plus nécessaire dans les petites entreprises où les marges de manœuvre sont
plus limitées en termes financiers et même d'équilibre général de l'entreprise elle
même.
Mais il ne peut pas y avoir de stratégie informatique si il n'y a pas de stratégie
d'entreprise.
64

65.
Causes et situations d'échecs, possibles
Un objectif n'est pas une prévision
L'objectif ne définit pas ce que sera le réalisé, mais ce que
l'on souhaiterait qu'il soit.
Le conseil informatique Les missions du conseiller en
informatique sont :
1 - Soupape de sûreté.
Il doit jouer la fonction du "Fou du roi". Il doit "oser dire" les
contre vérités issues de la politique menée par le décideur,
donner la véritable image renvoyée par les décisions prises.
2 - Contre pouvoir informatique.
Les conséquences des options proposées entre lesquelles il
va falloir choisir doivent être décrites pour que le décideur
puisse les mesurer pleinement. Ceci dans le but de s'assurer
que toutes les alternatives ont bien été proposées.
65

66.
Causes et situations d'échecs, possibles
3 - Retour d'informations
Transmettre l'information décisionnelle aux endroits stratégiques en court-circuitant
les canaux normaux. Ceci étant le pendant de la fonction "oser dire".
Cette fonction de transmission des informations est essentielle et permet de briser
l'isolement du décideur.
L'intelligentsia
Pour éviter les divers bourdons, aux avis autorisés ou s'autorisant des avis et
virevoltants autour du système de décision, et finissant bien sûr par aliéner la liberté
de choix du dit système, il convient de :
1 - Identifier précisément pour tout projet informatique :
- qui a décidé de commander l'automatisation d'un besoin ?
- qui contrôlera, vérifiera la conformité de la livraison avec le besoin exprimé et avec
quel jeu de recette ?
- qui prendra la décision de payer et qui payera effectivement la réalisation ?
66

67.
Causes et situations d'échecs, possibles
Ces trois hommes, qui peuvent être une seule et même personne, sont à identifier
absolument ainsi que leur système, formel ou non d'information et de contrôle .
2 - Quelle est l'alternative ?
Les solutions uniques en informatique sont rarissimes. La solution unique doit être
considérée comme anormale et " quelle est l'alternative" doit être la règle, même si la
découverte de l'alternative entraîne une dépense en énergie et ouverture sur des
solutions externes.
3 - Le chef de projet possède-t-il les qualités suivantes ?
- c'est un leader reconnu naturellement, et suivi par les acteurs du projet et les
membres de son équipe.
- c'est un manager, pilote du projet, respectueux des décisions du client, solidaire des
membres de son équipe.
- c'est un technicien, ne connaissant pas que les techniques informatiques, mais aussi
et surtout, celles de relations humaines et d'organisation.
- c' est un homme ayant un comportement enthousiaste, dynamique et positif ; car il
est bien le moteur de l'équipe, donnant l'âme du projet
67

68.
Causes et situations d'échecs, possibles
Ne faire que ce qui est demandé
Il ne faut pas construire un château si
une chaumière est demandée.
Il ne faut pas disperser les énergies sur
des développements annexes, mais créer
des points de contrôle et de non retour
pour éviter toute déviation.
68
Il faut se donner les moyens de vérification sur les délais, les coûts, la quantité
réalisée, la qualité et sur les moyens mis en oeuvre pour y parvenir.
L'utilisateur final, l'acteur effectif de la tâche en cours, doit être celui qui valide
cette tâche. Le décideur n'a pas les moyens, car n'ayant pas la connaissance
quotidienne de l'information élémentaire, de valider chaque phase de la
réalisation.

69.
Causes et situations d'échecs, possibles
La panacée universelle
L'informatisation à toutes les sauces ne peut
pas être un remède à un manque
d'organisation.
Si vous informatisez un "foutoir", vous aurez
un "foutoir" automatique semant la panique
avec la rapidité d’une machine.
69
Il faut organiser avant d'informatiser. Il est fréquent qu'une bonne organisation
ou réorganisation apporte de bien meilleurs résultats et à un bien moindre
coût qu'une informatisation.

70.
Causes et situations d'échecs, possibles
Les explorateurs
Ne pas confondre être un pionnier et être le premier
Les nouvelles techniques, gestionnaires de B.D., systèmes d'exploitation, langages,
transmissions, méthodes de stockage abondent et se succèdent avec rapidité. Il
convient de les suivre mais avec un minimum de décalage.
Si un fournisseur ne peut pas montrer au moins un site déjà installé et depuis un temps
permettant d'apprécier la fiabilité de la solution, il convient qu'il s'engage à mettre à la
disposition de l'acheteur ses compétences propres qui seront détachées sans charge
financière jusqu'à ce que les objectifs fixés soient atteints.
Il faut être ouvert sur l'extérieur
Il est indispensable de voir les solutions adoptées dans des organisations similaires,
fréquenter les clubs d'utilisateurs pour partager les expériences sur les mêmes outils et
avec les mêmes méthodes. Il ne faut pas chercher à réinventer systématiquement le
monde. Il faut chercher à utiliser ce qui est industriel plutôt que d'élaborer des
produits artisanaux.
70

71.
Causes et situations d'échecs, possibles
Il faut accorder des délais aux nouveautés
Les techniques nouvelles ont toujours l'ambition de traiter
mieux et plus vite. Elles règlent généralement
effectivement les problèmes qui existent, mais en font
apparaître d'autres qui perturbent les plannings
optimisés.
Il est donc souhaitable dès lors qu'une technique nouvelle
est adoptée, de majorer les délais prévisibles afin
d'intégrer les inévitables aléas liés au temps d'assimilation
de la nouvelle technique.
71

72.
Causes et situations d'échecs, possibles
La doctrine
Une référence est souhaitable, mais elle ne doit pas être figée, repoussant alors toute
possibilité d'évolution.
Il faut accepter l'évolution des besoins. Figer les besoins dans le temps serait une
erreur. Il est contre la nature des systèmes d'information de stopper la prise en compte
des besoins des clients.
Le besoin doit être satisfait dans un délai maximal. Le délai entre la satisfaction et
l'expression d'un besoin ne doit pas dépasser la double de la prévision initiale sous
peine de voir des procédés de remplacement se mettre en place supprimant ainsi le
besoin.
Pour négocier un délai avec un client il est fondamental de connaître ce qui peut être
accepté par celui-ci, car correspondant à son cycle normal de production. Il convient
donc de se renseigner sur la durée du dit cycle. Il est en effet rarement acceptable de
ne pas satisfaire tout ou partie du besoin pour le prochain cycle de production.
L'utilisateur ressentirait une frustration de la non satisfaction de son besoin au
moment opportun.
72

73.
Causes et situations d'échecs, possibles
Prévoir
Si les délais et coûts annoncés sont
périodiquement réajustés de même que
les prévisions au niveau des réalisations,
toute confiance disparaît tant vis à vis
des estimations que des réalisations.
73
Il en découle qu'il faut collecter suffisamment d'informations et suffisamment
pertinentes sur les données et traitements du besoin à informatiser, sur
l'organisation de la fonction à automatiser en éléments chiffrés et en
fréquences de répétitions ainsi que sur les hommes concernés.

74.
Causes et situations d'échecs, possibles
Prévoir
• Toute prévision étant nécessairement fausse, il convient de noter les hypothèses
corollaires aux estimations faites. Ce qui permettra au fur et à mesure de leurs
vérifications d'affiner la prévision.
• L'erreur est normale. L'erreur humaine est possible à tous les stades d'une mise en
œuvre informatique. Elle aura d'autant plus de conséquences qu'elle aura été faite
tôt dans le déroulement du projet.
• L'erreur coûte cher, car si elle est normale, elle possède également un coût qui sera
inversement proportionnel à son origine.
Tel ou tel modèle ayant réussi dans un cas précis ne fonctionnera pas dans un autre
cas. Car chaque cas est particulier ainsi que ses composantes. Vouloir faire de
l'extrapolation est très dangereux.
74

75.
Causes et situations d'échecs, possibles
Chiffrer les prévisions
Une estimation de réalisation ne peut être
faite sur un barème établi et moins encore
sur les critères personnels de l'auteur de la
prévision relevés 15 ans au par avant lorsqu'il
développait. C' est donc à chaque
développeur de faire sa propre prévision en
fonction de ses moyens et capacités propres
sur la partie du projet qui le concerne.
75
L'unité d'évaluation des réalisations informatiques est le jour/homme. Pour
un travail d'une unité, l'écart entre prévisionnel et réalisé peut atteindre 100
%. Il n'est pas rare en effet que pour un travail prévu d'une journée, selon
des contraintes même totalement externes, il soit réellement terminé au
bout de 2 jours.

76.
Causes et situations d'échecs, possibles
Chiffrer les prévisions
Donc si sur l'unité de base la plus fine l'écart
peut être de 1 à 2, la somme des unités
élémentaires peut également varier dans les
mêmes proportions.
76
A défaut d'expérience en le domaine on peut utiliser la formule suivante :
Temps estimé = ((T optimiste)+(4 * T vraisemblable)+(T pessimiste))/ 6

77.
Causes et situations d'échecs, possibles
Les délais
Si les délais ne sont pas respectés parce qu'imposés. Si lorsqu'ils le sont c'est au
détriment de la qualité ou à un coût bien supérieur aux prévisions. Alors la
démotivation est générale. Les réclamations ultérieures aux livraisons viennent
retarder les chantiers en cours. Un cycle pervers délais irréalistes et retards par
rectifications s'installe.
Combien de temps ?
Une des questions primordiales et qui revient sans cesse à l'analyste programmeur est :
"çà sera prêt quand, combien de temps te faut-il pour faire çà ?". A cette question la
réponse doit être :
- Ca dépend :
1. des moyens à disposition
2. de la date de début
3. des conditions de l'environnement
4. du niveau des moyens utilisés
77

78.
Causes et situations d'échecs, possibles
Toute prévision de réalisation dépend de ces quatre éléments. On a trop souvent
tendance à oublier le point 2. Il est fréquent de négocier une date de livraison alors
que la date de départ est déjà dépassée pour atteindre la date de livraison compte
tenu des moyens. Le délai de livraison sera souvent différent du délai moyen prévu en
fonction des moyens mis en œuvre et de l'environnement.
78
Dire oui au délai mais avec contreparties
Le réalisateur doit savoir dire non face à un
délai irréaliste. Il doit savoir reporter une
date sous prétexte que les craintes
prévisibles se sont réalisées et doit pouvoir
justifier d'un report en fonction de risques
non prévisibles au début.
En cas d'acceptation du délai, il faut systématiquement soit augmenter le coût
car de nouveaux moyens devront être mis en œuvre ou baisser la quantité
et/ou la qualité à réaliser. Il convient d'éduquer le client et lui faire prendre
conscience des composantes possibles et des choix qu'il doit entreprendre. Le
réalisateur propose et le client dispose !

79.
Causes et situations d'échecs, possibles
Pas de challenge sans repos
Le pari, le défi lancé à une équipe est une forme de motivation à condition que le
challenge soit réellement atteignable.
Mais il n'est pas possible de relever des défis 365 jours par an. Le moyen humain
comme tout autre à besoin de périodes de repos, de décompression.
Le client doit être responsable
Le client doit absolument prendre conscience qu'imposer un délai sans négocier une
autre composante, coût, quantité, qualité est irréaliste. Il doit d'autre part être vigilant
si face à sa demande aucune réaction ne vient du réalisateur.
Le réalisateur de son côté est également déontologiquement accusable de ne l'avoir
pas signalé lorsqu'il a accepté le délai .
Planifier le projet
Le temps de planification qui permet d'élaborer la stratégie de développement doit
être au moins égal à 10 % du délai total du chantier. C'est à ce stade que sont définis
les méthodes de conception, de développement et de tests.
79

80.
Causes et situations d'échecs, possibles
Il faut disposer d'outils de gestion de projet
L'équilibre et l'adéquation entre délai et moyens doivent former la réponse à toute
demande. S'en référer à la seule compétence et expérience du chef de projet n'est
possible qu'en l'absence de difficultés.
Les pauses ne sont pas un crime
Quelles soient courtes et répétitives (café) ou plus longues (repos), les pauses sont
indispensables. On ne peut jouer un challenge ni chaque jour ni chaque heure. Les
exploits sont un dépassement qui demande réparation. L'exceptionnel ne peut devenir
ordinaire à moyen égal.
Le chemin le plus court est la ligne droite
Il est souvent beaucoup plus difficile de faire simple que de faire compliqué. Le faire
compliqué ne nécessite souvent que de mettre bout à bout des techniques ou d'éviter
de comprendre à fond un problème à régler.
Le faire simple implique de digérer ces techniques et problèmes pour rendre
transparents leurs inconvénients. Faire simple demande donc des efforts. Un
développeur ne doit pas être avare de ses efforts.
80

81.
Causes et situations d'échecs, possibles
Faire des choix
Tout demain ou l'essentiel tout de suite
Les besoins doivent être répertoriés en trois catégories, en relation avec la réalisation
de la finalité de l'entreprise :
1 - le fondamental à faire immédiatement
2 - l'important à faire rapidement
3 - l'accessoire à faire ultérieurement
Le coût de l'exceptionnel ou du rarissime est souvent proportionnellement très élevé
et son traitement doit donc être envisagé avec une extrême prudence.
Sur mesure ou prêt à porter
Le sur mesure est toujours préférable au produit confectionné en série. Mais si le sur
mesure a les mêmes caractéristiques que le confectionné ou que l'attente du sur
mesure est telle que la mise en place dans des délais beaucoup plus courts aurait put
globalement satisfaire la majeur partie des besoins, est-il vraiment opportun de vouloir
faire du sur mesure ?
81

82.
Causes et situations d'échecs, possibles
Tac au tac
Le client préférera toujours une réponse immédiate à une réponse différée. Mais le
temps réel coûte cher, surtout lorsque plusieurs applications cohabitent et avec des
bases de données différentes. Bien que le temps réel fasse plaisir, il importe toujours
de se demander :
1 - quelle est la fréquence des mises à jour inter-application ?
2 - quel est le coût de ces mises à jour en temps réel ?
3 - quelles seraient les conséquences si les mises à jour n'étaient pas faites en temps
réel ?
Il semble bien que la mise à jour en temps réel ne soit que très rarement une nécessité
absolue. Généralement un décalage de quelques heures ou d'une journée est
parfaitement acceptable. L'idéal serait bien sûr le partage de la même base de
données.
Le high tech
Il est souvent préférable d'un point de vue financier et pour un résultat pratiquement
identique lorsqu'une compétence particulière est impérative de recruter un BAC + 2 et
de le former à la technique voulue plutôt que de recruter un BAC + 4 ou 5 possédant
déjà cette technique, vu la rapidité d'évolution des dites techniques.
82

83.
Causes et situations d'échecs, possibles
Qui doit décider quoi
Les choix techniques sont à faire par les informaticiens.
Le client est roi, mais le roi a un budget et tous les désirs
du roi ne sont pas réalisables.
Le client ne doit pas faire les choix techniques, mais les
conséquences des choix techniques doivent lui être
montrés et prouvés. Si le choix technique influe sur les
conséquences le client doit être d'accord avec le choix
ou avec les conséquences.
La validation finale d'un traitement ne peut être faite
que par l'utilisateur final et en exploitation réelle.
La livraison est systématiquement suivie de corrections
ou adaptations liées à l'évolution inévitable du besoin
de l'utilisateur entre le moment de l'expression de la
demande et le moment de la satisfaction de cette
même demande.
83

84.
Causes et situations d'échecs, possibles
Qui doit décider quoi
Pas de développement sans cahier des charges.
Les corrections ne seront pas systématiquement faites par le développeur initial, ce qui
implique que la documentation et le complément normal du programme.
Le livre de recette, véritable contrat de réception devra dresser la liste exhaustive des
opérations à réaliser pour valider le produit.
Il ne faut absolument pas déroger à :
1 - pas de développement sans cahier des charges.
2 - pas de programmation sans commentaires et documentation d'utilisation.
3 - pas de livraison sans jeu de recette.
4 - pas de développement sans vérification des compétences du développeur ne serait
ce que par le contact avec les anciens utilisateurs de la compétence en question.
84

85.
Causes et situations d'échecs, possibles
Valider toujours valider
Il faut qualifier, c'est à dire vérifier la conformité du
produit à la demande initiale avant toute livraison et ce
le plus tôt possible. Quelque soit le degré d'exactitude
des spécifications et quelque soit la qualité du
développement car l'erreur est toujours possible.
85
La ou les personnes qualifiant un produit doivent être assimilées à des pilotes
d'essais et doivent posséder à la fois la technique et le comportement d'un
utilisateur final.
Un bon pilote d'essais n'est réellement opérationnel qu'après une longue
formation. Mais revers de la médaille, il doit aussi garder la fraîcheur et la naïveté
d'un utilisateur même après une longue expérience.

86.
Causes et situations d'échecs, possibles
La réunionite aiguë
Les réunions sont indispensables au bon
déroulement d'un projet. Néanmoins il
est impératif d'éviter de tomber dans
l'excès et de veiller à ce quelles soient
fructueuses. C'est à dire quelles soient
un lieu de synthèses et de décisions.
86
Ce qu'il faut éviter
Pas de diffusion d'informations au cours d'une réunion. Elle doit être faite
avant (préparation de la réunion).
Pas d'étrangers à la réunion. Pour un problème donné, faire appel aux acteurs
quotidiens et non à leur représentant hiérarchique car il y a nécessairement
perte d'informations originales. Tant pis pour la préséance et tant mieux pour
l'efficacité !

87.
Causes et situations d'échecs, possibles
Pas de réunion sans animateur, le meilleur animateur n'étant pas
nécessairement le plus élevé dans la hiérarchie ni le plus compétent
techniquement.
La fonction d'animateur de réunion est quelque chose qui s'apprend.
L'animateur doit faire émettre les différents points de vue et donc veiller à la
réceptivité des membres du groupe. Il ne doit pas décider mais faire décider le
groupe.
La durée des réunions ne doit pas dépasser deux heures par demi-journée et
stratégiquement doit être comprise entre 9 h 30 et 11 h 30 ou 14 h 30 et 16 h
30. Il faut systématiquement laisser de la place au travail personnel.
Il ne faut pas laisser de place à la mémoire. Il faut systématiquement noter par
écrit un résumé des décisions prises en réunion.
87

88.
Causes et situations d'échecs, possibles
Gérer l'ordre du jour des réunions
Un ordre du jour pour chaque réunion doit être
clairement établi et très précis sur les sujets abordés
et la durée qui lui sera consacré.
L'identité et la qualité des participants doit figurer de
façon claire.
La situation spatio-temporelle doit être précise (lieu,
date, heure début, heure fin).
Pour les réunions à caractère répétitif, le premier sujet
doit être de fixer les trois points précédents.
Le sujet questions diverses est à prohiber totalement
88

89.
Causes et situations d'échecs, possibles
La rétention d'informations
Le dialogue utilisateur concepteur doit être formalisé. Toutes les questions
du concepteur doivent être notées par écrit. Toutes les questions doivent
être systématiquement répertoriées. Le concepteur doit poser toutes les
questions nécessaires pour qu'aucun voile ne subsiste sur aucun sujet.
L'utilisateur doit suivre l'évolution du produit commandé et réclamer si
nécessaire des points de contrôle supplémentaires.
Il faut éviter la dispersion physique des membres d'un même projet ou
mettre en place une organisation de communication d'informations en
temps réel pour éviter toute perte due à l'isolement.
89

90.
Causes et situations d'échecs, possibles
Motivation des acteurs
Motiver les acteurs doit être la règle pour :
1 - produire de la qualité chez les développeurs.
Celle-ci s'obtient comme pour tout artiste par la
reconnaissance du travail accompli. Le non-
travail contribuant à la démotivation.
90
Il faut donc faire prendre conscience au développeur que la partie de son travail
qui amène la qualité n'est pas du non-travail mais du travail effectif. Il convient
alors que la phase de recherche de qualité des programmes informatiques donne
lieu à la production de ses propres indicateurs de qualité, capables de mesurer
avec pertinence l'accroissement de la qualité apportée.

91.
Causes et situations d'échecs, possibles
2 - déterminer des objectifs intermédiaires
qui doivent être :
- Concrets, c'est à dire matérialisés par des
documents pouvant être validés par le
client.
- Pratiques, donc pouvant être exploités par
le client dans son langage habituel.
- Formels, parce qu'attendus dans une
présentation usuelle.
91
3 - atteindre les objectifs par la motivation.
La motivation ne s'obtient pas par le salaire qui n'est qu'un facteur de diminution
de l'insatisfaction (échelle de satisfaction de Herzberg). Elle s'obtient par la
reconnaissance de l'homme dans son travail, par les responsabilités accordées.

92.
Causes et situations d'échecs, possibles
4 - sachons avoir une écoute active.
L'écoute est un art. Trop d'informations sont transmises sans être captées, trop de
sensations sont exprimées sans être saisies. L'écoute doit devenir une règle pour
chacun et il convient bien de réapprendre à écouter.
5 - savoir juger les hommes.
Il faut juger leur travail ou plutôt la qualité de leur travail. Pour cela il conviendrait
d'oublier qui l'a réalisé pour émettre un jugement sain sans parasitage d'informations
connues ou inconnues sur le personnage réalisateur.
La démarche marketing de la solution
Que ce soit pour un client ou en interne, une solution doit toujours "être vendue". Il
faut faire savoir pourquoi et pour qui le projet est réalisé. Il faut affirmer que la
vocation du projet est de servir l'utilisateur final et que toute l'activité déployée pour le
mettre en œuvre tend à la satisfaction de l'utilisateur final.
92

93.
Causes et situations d'échecs, possibles
L'utilisateur a exprimé un besoin ou on a exprimé ce besoin pour lui. Mais ceci ne suffit
pas pour qu'il soit satisfait par la livraison quelque soit le degré de qualité du produit
livré.
Il faut en effet susciter l'attente de l'utilisateur final pour que la livraison soit ressentie
comme une délivrance et non pour qu'il la ressente comme une contrainte et une
négation de ses compétences et méthodes de travail antérieures.
Ceci étant valable même en cas d'informatisation déjà existante; sous peine de se voir
opposer un refus et une opposition catégorique.
Il n'y a de pire utilisateur-démolisseur que celui qui ne veut trouver dans un nouveau
produit que la preuve de la supériorité de l'outil ancien. En ce sens aucune
transposition matérielle ou logicielle ne doit se faire sans être accompagnée de
fonctions nouvelles.
93

94.
Causes et situations d'échecs, possibles
Qui doit être chef de projet ?
Le chef de projet n'est pas nécessairement le
plus compétent ou performant techniquement
ou plus ancien dans la maison, mais celui qui
saura sûrement par une formation ou une
compétence appropriée gérer les relations
humaines, les conflits dans les priorités ou
l'affectation des ressources ainsi que les
exceptions qui ont tendance à remettre en
cause homogénéité et automatisation.
94
Il doit vivre le projet avec plusieurs longueurs d'avance afin de pouvoir mieux se
préparer à recevoir les événements de l'environnement devant influer sur le
cours du déroulement du projet.

95.
Causes et situations d'échecs, possibles
Qui doit être chef de projet ?
Si il possède des compétences dans le domaine
de l'utilisateur sa tâche sera hautement
facilitée.
Le chef de projet doit être reconnu non
seulement de son équipe mais aussi de sa
hiérarchie.
Il doit entretenir motivation et délégation de
responsabilités pour obtenir la participation
des membres de l'équipe.
95

96.
Causes et situations d'échecs, possibles
Un seul responsable
Les objectifs sont mouvants et changeants. Les attributions des responsabilités et des
ressources ne sont pas stables. Les membres du projet sont multi-dirigés, multi-
contrôlés, multi-motivés entraînant des ordres et des contrordres le projet n'est en fait
pas dirigé. Il faut :
1 - définir les contributions de chacun à l'objectif final.
Les missions confiées sans explication du contexte de l'objectif entraînent une
démotivation des acteurs.
Pour bien prendre en compte les besoins du client, toutes les missions et objectifs
intermédiaires doivent être présentés à leurs réalisateurs par rapport à leur
contribution à l'objectif final.
2 - le responsable de projet doit être un "emmerdeur".
Il doit être celui qui réclame confirmation au client de la demande ou si il est toujours
sur la bonne trajectoire; qui rappelle à ses équipes les objectifs intermédiaires à
atteindre pour respecter l'objectif final; qui relance constamment ceux qui doivent
répondre aux questions restées sans réponse; qui confirme les points de contrôle non
atteints; qui écrit ce qui risque d'apporter une divergence par rapport au contrat initial;
qui contourne la mauvaise foi, les erreurs et les oublis; qui s'attend à l'ingratitude ...
96

97.
Causes et situations d'échecs, possibles
Il doit faire preuve d'humilité devant le risque de ne pas atteindre les objectifs. Il
s'évertue à supprimer les hypothèses pour apporter plus de précision à ses prévisions.
Le responsable de projet peut très bien ne pas être informaticien au sens informatique
mais doit être informaticien au sens information et il est même souhaitable qu'il ait
une expérience effective du domaine de l'utilisateur du projet qu'il dirige.
Avant tout gestionnaire des hommes, donc des conflits, il est le moteur de l'équipe.
Il n'est pas aimé, il atteint des résultats.
3 - disposer obligatoirement de marges de manœuvre.
Les prévisions des projets informatiques sont toujours fausses. Tout l'art du manager et
de minimiser les écarts entre le prévisionnel et le réalisé.
Il convient donc nécessairement de prévoir l'imprévisible car la gestion de projet
informatique est toujours une aventure, attendu que la part d'inconnu concerne trop
de paramètres agissants sur l'objectif final.
97

98.
Causes et situations d'échecs, possibles
 L'utilisateur a-t-il exprimé tous les besoins qu'il souhaitait exprimer ? Jamais.
 Les a-t-il convenablement exprimés ? Rarement.
 Les analyses reflètent-elles le besoin exprimé ? Parfois.
 Les développeurs n'ont-ils pas tendance à simplifier ou a interpréter ? Souvent.
 Les ressources prévues sont-elles disponibles entièrement ? Quasiment impossible.
Souvenez vous de la balançoire !
L'art du responsable de projet est de déterminer la taille des marges de manœuvre. En
l'absence d'expérience en la matière, une fourchette de 10 à 15 % peut être retenue.
98

99.
Causes et situations d'échecs, possibles
Gérer les conflits
Ce qu'il faut c'est gérer les conflits, pas les éviter. Pour ce faire il convient de :
1 - quantifier les résultats attendus, définir les objectifs en termes de : qualité,
quantité, coût, délai.
99
La négociation ne pouvant se faire que sur les
moyens d'atteindre les composantes de
l'objectif.

100.
Causes et situations d'échecs, possibles
2 - prendre les décisions à temps.
Une décision doit être préparée, par une note écrite, concise et précise qui pose le
problème. Le décideur doit être disponible et accessible pour décider. La décision doit
être connue, elle ne prend effet que lorsque ceux qui sont concernés en ont
connaissance.
3 - pas de consensus informel.
Tout doit être notifié par écrit et validé par les différents intervenants. Le verbal ne
peut être qu'une source de désaccords.
4 - fermer le parapluie.
Un maître d‘œuvre, un chef de projet doit savoir et pouvoir prendre la décision de
passer à une étape ultérieure même si 100 % des cas n'ont pas été testés. Le 100 %
n'est généralement pas atteignable car il nécessite temps et argent et risque de
démoraliser les équipes de développement. Il faut savoir estimer le risque.
100

101.
Causes et situations d'échecs, possibles
Il faut également gérer les équipes. Les hommes qui ne s'entendent pas ne se limitent
pas à s'ignorer. Ils dépensent une partie de leur énergie à rectifier, contrecarrer,
saboter ce que d'autres font. Il convient alors de :
1 - apprécier par le résultat et non par le comportement.
2 - définir spécifiquement les missions, les domaines de compétence, les relations des
différents intervenants.
3 - canaliser les motivations.
Il est nécessaire de créer des conditions d'émission et de réception des émotions des
acteurs du projet. Les émotions ne doivent pas être ignorées mais canalisées.
101

102.
Causes et situations d'échecs, possibles
Eliminer luttes et animosités
1 - il faut tout d'abord valoriser la production
logicielle, même si elle est faite en interne et
n'apportera pas de chiffre d'affaire, par une
comptabilité analytique par exemple. Les auteurs d'un
projet doivent pouvoir se satisfaire de la valeur
ajoutée qu'ils ont produit.
2 - les conflits sont normaux, mais ils doivent être
canalisés pour la bonne cause du projet.
102

103.
Causes et situations d'échecs, possibles
Pour résoudre un conflit il faut :
- Écrire la nature du problème rencontré et le formaliser en termes d'objectifs. C'est à
dire qu'il doit être quantifiable, mesurable et programmable dans le temps. Le
problème ne doit pas être une sensation ou une impression, car sa résolution se rait de
même nature.
- Lister et écrire les conséquences du problème sur les objectifs intermédiaires et
finaux du projet. En d'autres termes il faut se dire : si je ne décide rien pour ce
problème voilà ce qui va arriver ...
- Lister et écrire les solutions possibles toujours par rapport aux objectifs du projet.
- Choisir la solution souhaitable et mesurer les conséquences du problème sur le projet
en terme de retard, coût, qualité ...
Il peut être utile de demander aux acteurs du problème de répondre aux 4 questions
par écrit. La synthèse et la recherche de la solution optimale s'en trouvent largement
facilités.
3 - La réalisation des logiciels n'est pas entièrement automatisable, l'homme y prend
une grande part.
103

104.
Causes et situations d'échecs, possibles
Cette ressource devra être sélectionnée, formée, rémunérée et appréciée à sa juste
valeur. Les éléments d'appréciation devront être communiqués aux intéressés avant le
début du travail, pour que chacun connaisse parfaitement les éléments de la mesure
de son travail.
4 - Les conflits sont normaux sur un chantier.
Son responsable est là avant tout pour les régler. Il peut y avoir conflit parce que les
objectifs du projet peuvent ne pas être clairs pour les acteurs ou parce que les
ressources affectées peuvent être insuffisantes en qualité ou en quantité.
Il est tentant de remplacer les hommes chargés de mener objectifs et ressources alors
qu'il serait peut être opportun de vérifier avec l'utilisateur la conformité des objectifs
intermédiaires ou l'adaptation des ressources aux nécessités.
Il est plus facile de remplacer le responsable que de remettre en cause la structure ou
le mode d'organisation du projet.
Efforçons nous de ne pas rechercher le coupable avant d'analyser les causes.
104

105.
Merci de votre attention
105