SlideShare une entreprise Scribd logo
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
Le tour de table des participants à cette formation
2
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
Organisation pratique de cette journée
9h-9h30 Accueil des participants et tour de table
9h30 - 10h30 La gestion de projets et les compétences requises
10h30 - 11h00 Pause
4
13h30 - 15h00 Les règles pour éviter de faire déraper un projet
11h00 - 12h30 Les outils clés du chef de projet
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
Programme de la formation
C’est quoi la gestion de projet ?
Atelier fil rouge : Retours d’Expérience
Quelles sont les qualités d’un bon chef de projet ?
Comment entretenir la motivation des équipiers du projet ?
5
Comment réaliser un tableau de bord du projet ?
Quelles sont les règles de la relation avec le commanditaire ?
Comment bien communiquer ?
Comment éviter de faire déraper un projet ?
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.
Gestion de projet 7
Introduction : C’est quoi la gestion de projet ?
La gestion de projet en 2 min : https://www.youtube.com/watch?v=KstwnJm4OO0
Gestion de projet 8
C’est quoi la gestion de projet ?
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 ?
C’est quoi la gestion de projet ?
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.
9Gestion de projet
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.
10Gestion de projet
1
2
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.
11Gestion de projet
3
Quelles sont les compétences requises du chef de projet ?
12
Gestion de projet 13
Zoom sur le métier de chef de projet
La vidéo: https://www.youtube.com/watch?v=NL_B9c7BIhs
Quelles sont les compétences requises du chef de projet ?
14
Lister une dizaine de compétences
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 les parties
prenantes
Un responsable
– Il dispose de moyens et
d'obligations
– Il doit tenir ses objectifs…
Gestion de projet 15
Le chef de projet est …
 Cadrage 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 16
Les missions du chef de projet sont multiples
Gestion de projet 17
Les soft skills
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.
Gestion de projet 18
Les compétences du chef de projet = une rose des vents
Gestion de projet 19
Les compétences du chef de projet
L’outil de la rose des vents
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.
Gestion de projet 20
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.
Gestion de projet 21
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
Gestion de projet 22
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 d’un 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.
Quelles sont les compétences à travailler parmi celle citées ?
23
Le plan de communication du projet
24
Gestion de projet 25
La communication, première compétence du chef de projet
Le lien vers la vidéo
Gestion de projet 26
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.
Gestion de projet 27
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.
Gestion de projet 28
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.
Gestion de projet 29
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 ?
Gestion de projet 30
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.
Comment entretenir la motivation des équipiers du projet ?
31
Gestion de projet 32
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
Gestion de projet 33
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
Gestion de projet 34
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
Gestion de projet 35
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
Gestion de projet 36
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.
Gestion de projet 37
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.
Quelles sont les règles de la relation avec le commanditaire ?
38
Gestion de projet 39
Les règles de la relation avec le commanditaire
Vidéo : transmettre la vision du commanditaire à l’équipe projet
Gestion de projet 40
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é.
Gestion de projet 41
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.
Gestion de projet 42
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
Gestion de projet 43
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
Gestion de projet 44
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.
Gestion de projet 45
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
Le tableau de bord du projet
46
Gestion de projet 47
Le tableau de bord du projet
La vidéo
Gestion de projet 48
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).
Comment éviter de faire déraper un projet ?
49
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.
50Gestion de projet
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.
51
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.
52
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 ?
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.
53
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.
54
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.
55
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.
56
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 ?
57
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
58
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.
59
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.
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.
60
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.
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.
61
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.
62
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.
63
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.
64
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.
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.
65
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.
66
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.
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.
67
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
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
68
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.
69
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 !
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.
70
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.
71
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 ?
72
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.
73
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.
74
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.
75
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.
76
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.
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.
77
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é !
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.
78
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
79
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.
80
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.
81
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.
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.
82
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.
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.
83
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.
84
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.
85
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.
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.
86
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 ...
87
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.
88
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.
89
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.
90
La négociation ne pouvant se faire que sur les
moyens d'atteindre les composantes de
l'objectif.
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.
91
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.
92
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.
93
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.
94
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.
95
Merci de votre attention
96

Contenu connexe

Tendances

Formation conduite de projet - Philippe Dornbusch
Formation conduite de projet - Philippe DornbuschFormation conduite de projet - Philippe Dornbusch
Formation conduite de projet - Philippe Dornbusch
Echecs et Stratégie
 
Conduire un appel d'offres sur un systeme informatique
Conduire un appel d'offres sur un systeme informatique Conduire un appel d'offres sur un systeme informatique
Conduire un appel d'offres sur un systeme informatique
Echecs et Stratégie
 
Conduire un appel d’offres pour la mise en œuvre d’un système d’information
Conduire un appel d’offres pour la mise en œuvre d’un système d’informationConduire un appel d’offres pour la mise en œuvre d’un système d’information
Conduire un appel d’offres pour la mise en œuvre d’un système d’information
Echecs & Stratégie
 
Analyse de processus et workflow
Analyse de processus et workflowAnalyse de processus et workflow
Analyse de processus et workflow
Echecs et Stratégie
 
Analyse de processus et workflow
Analyse de processus et workflowAnalyse de processus et workflow
Analyse de processus et workflow
Echecs et Stratégie
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
Echecs et Stratégie
 
Formation Gestion de projet
Formation Gestion de projetFormation Gestion de projet
Formation Gestion de projet
Echecs et Stratégie
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
Samer EL SAWDA, Ph.D.
 
Les clés pour conduire un projet en entreprise
Les clés pour conduire un projet en entrepriseLes clés pour conduire un projet en entreprise
Les clés pour conduire un projet en entreprise
Echecs & Stratégie
 
Management de Projet International
Management de Projet InternationalManagement de Projet International
Management de Projet International
Riana Andrieux
 
Gestion de projet power point
Gestion de projet power pointGestion de projet power point
Gestion de projet power point
Webagogo
 
Projet les fondamentaux - version 2014
Projet les fondamentaux -  version 2014Projet les fondamentaux -  version 2014
Projet les fondamentaux - version 2014
Rémi Bachelet
 
Management de projet
Management de projetManagement de projet
Management de projet
Aboubakr Moubarak
 
Gestion de projets
Gestion de projetsGestion de projets
Gestion de projets
Sana REFAI
 
Gestion de Projets
Gestion de Projets Gestion de Projets
Gestion de Projets
Said Sadik
 
Cours de gestion de Projet - Les Fondamentaux
Cours de gestion de Projet - Les FondamentauxCours de gestion de Projet - Les Fondamentaux
Cours de gestion de Projet - Les Fondamentaux
Rémi Bachelet
 
Outils d'organisation de Projet
Outils d'organisation de ProjetOutils d'organisation de Projet
Outils d'organisation de Projet
Rémi Bachelet
 
Organisation et Management "par projet"
Organisation et Management "par projet"Organisation et Management "par projet"
Organisation et Management "par projet"
Communauté d'agglomération du Pays de Grasse
 
Méthodologie de projet présentation 2
Méthodologie de projet présentation 2Méthodologie de projet présentation 2
Méthodologie de projet présentation 2
Gilles Ducloux
 

Tendances (20)

Formation conduite de projet - Philippe Dornbusch
Formation conduite de projet - Philippe DornbuschFormation conduite de projet - Philippe Dornbusch
Formation conduite de projet - Philippe Dornbusch
 
Conduire un appel d'offres sur un systeme informatique
Conduire un appel d'offres sur un systeme informatique Conduire un appel d'offres sur un systeme informatique
Conduire un appel d'offres sur un systeme informatique
 
Conduire un appel d’offres pour la mise en œuvre d’un système d’information
Conduire un appel d’offres pour la mise en œuvre d’un système d’informationConduire un appel d’offres pour la mise en œuvre d’un système d’information
Conduire un appel d’offres pour la mise en œuvre d’un système d’information
 
Analyse de processus et workflow
Analyse de processus et workflowAnalyse de processus et workflow
Analyse de processus et workflow
 
Analyse de processus et workflow
Analyse de processus et workflowAnalyse de processus et workflow
Analyse de processus et workflow
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
Formation Gestion de projet
Formation Gestion de projetFormation Gestion de projet
Formation Gestion de projet
 
Initiation à la gestion de projet
Initiation à la gestion de projetInitiation à la gestion de projet
Initiation à la gestion de projet
 
Les clés pour conduire un projet en entreprise
Les clés pour conduire un projet en entrepriseLes clés pour conduire un projet en entreprise
Les clés pour conduire un projet en entreprise
 
Management de Projet International
Management de Projet InternationalManagement de Projet International
Management de Projet International
 
Gestion de projet power point
Gestion de projet power pointGestion de projet power point
Gestion de projet power point
 
Projet les fondamentaux - version 2014
Projet les fondamentaux -  version 2014Projet les fondamentaux -  version 2014
Projet les fondamentaux - version 2014
 
Management de projet
Management de projetManagement de projet
Management de projet
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
Gestion de projets
Gestion de projetsGestion de projets
Gestion de projets
 
Gestion de Projets
Gestion de Projets Gestion de Projets
Gestion de Projets
 
Cours de gestion de Projet - Les Fondamentaux
Cours de gestion de Projet - Les FondamentauxCours de gestion de Projet - Les Fondamentaux
Cours de gestion de Projet - Les Fondamentaux
 
Outils d'organisation de Projet
Outils d'organisation de ProjetOutils d'organisation de Projet
Outils d'organisation de Projet
 
Organisation et Management "par projet"
Organisation et Management "par projet"Organisation et Management "par projet"
Organisation et Management "par projet"
 
Méthodologie de projet présentation 2
Méthodologie de projet présentation 2Méthodologie de projet présentation 2
Méthodologie de projet présentation 2
 

Similaire à Gestion de Projet

Comment structurer, conduire et gérer un projet2.pptx
Comment structurer, conduire et gérer un projet2.pptxComment structurer, conduire et gérer un projet2.pptx
Comment structurer, conduire et gérer un projet2.pptx
kowiouABOUDOU1
 
Chef de projet et management humain
Chef de projet et management humainChef de projet et management humain
Chef de projet et management humain
nodesway
 
Project managementcourseoutline rymtlijanibahrini
Project managementcourseoutline rymtlijanibahriniProject managementcourseoutline rymtlijanibahrini
Project managementcourseoutline rymtlijanibahrini
SESAME
 
Le management de projet par Fethi FERHANE
Le management de projet par Fethi FERHANELe management de projet par Fethi FERHANE
Le management de projet par Fethi FERHANE
Fethi Ferhane
 
gestiondeprojet-170413112302.pp,bkjhghthkt
gestiondeprojet-170413112302.pp,bkjhghthktgestiondeprojet-170413112302.pp,bkjhghthkt
gestiondeprojet-170413112302.pp,bkjhghthkt
AbdelkarimAaziz1
 
[Modules de spécialisation] Programme GdP7
[Modules de spécialisation] Programme GdP7[Modules de spécialisation] Programme GdP7
[Modules de spécialisation] Programme GdP7
Bich Van Hoang
 
CIO Mag : Les Best Practices Finatech pour la Gestion des Projets TI
CIO Mag : Les Best Practices Finatech pour la Gestion des Projets TICIO Mag : Les Best Practices Finatech pour la Gestion des Projets TI
CIO Mag : Les Best Practices Finatech pour la Gestion des Projets TI
Finatech Group S.A.
 
La Gestion de Projet.pdf
La Gestion de Projet.pdfLa Gestion de Projet.pdf
La Gestion de Projet.pdf
badrfathallah2
 
D’un pilotage de projet traditionnel à innovant, quelle marche à suivre ?
D’un pilotage de projet traditionnel à innovant, quelle marche à suivre ?D’un pilotage de projet traditionnel à innovant, quelle marche à suivre ?
D’un pilotage de projet traditionnel à innovant, quelle marche à suivre ?
dibs-conseil
 
Management de projet slide share
Management de projet slide shareManagement de projet slide share
Management de projet slide share
Emmanuel Urschel Villier
 
[MOOC GdP] Spécialisations GdP9
[MOOC GdP] Spécialisations GdP9[MOOC GdP] Spécialisations GdP9
[MOOC GdP] Spécialisations GdP9
Bich Van Hoang
 
Gestion de projet chapitre 0 ppt projets
Gestion de projet chapitre 0 ppt projetsGestion de projet chapitre 0 ppt projets
Gestion de projet chapitre 0 ppt projets
red1packeta
 
Gestion_de_projet_université.ppt
Gestion_de_projet_université.pptGestion_de_projet_université.ppt
Gestion_de_projet_université.ppt
jouaiti1
 
Cours sur les bases de la Gestion_de_projet_université.ppt
Cours sur les bases de la Gestion_de_projet_université.pptCours sur les bases de la Gestion_de_projet_université.ppt
Cours sur les bases de la Gestion_de_projet_université.ppt
ghiz-
 
Support GESPRO-2023-2024.pptx
Support GESPRO-2023-2024.pptxSupport GESPRO-2023-2024.pptx
Support GESPRO-2023-2024.pptx
OlyvierNzighou1
 
Project Management Course Outline
Project Management Course OutlineProject Management Course Outline
Project Management Course Outline
SESAME
 
Le management projet 2011
Le management projet 2011Le management projet 2011
Le management projet 2011
mimousaid
 
gestion_de_projet_universite.ppt
gestion_de_projet_universite.pptgestion_de_projet_universite.ppt
gestion_de_projet_universite.ppt
AyoubJafri1
 
Conduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & OutilsConduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & Outils
stephanie vincent
 
Comment mettre en place un bureau de projets avec succès !
Comment mettre en place un bureau de projets avec succès !Comment mettre en place un bureau de projets avec succès !
Comment mettre en place un bureau de projets avec succès !
PMI-Montréal
 

Similaire à Gestion de Projet (20)

Comment structurer, conduire et gérer un projet2.pptx
Comment structurer, conduire et gérer un projet2.pptxComment structurer, conduire et gérer un projet2.pptx
Comment structurer, conduire et gérer un projet2.pptx
 
Chef de projet et management humain
Chef de projet et management humainChef de projet et management humain
Chef de projet et management humain
 
Project managementcourseoutline rymtlijanibahrini
Project managementcourseoutline rymtlijanibahriniProject managementcourseoutline rymtlijanibahrini
Project managementcourseoutline rymtlijanibahrini
 
Le management de projet par Fethi FERHANE
Le management de projet par Fethi FERHANELe management de projet par Fethi FERHANE
Le management de projet par Fethi FERHANE
 
gestiondeprojet-170413112302.pp,bkjhghthkt
gestiondeprojet-170413112302.pp,bkjhghthktgestiondeprojet-170413112302.pp,bkjhghthkt
gestiondeprojet-170413112302.pp,bkjhghthkt
 
[Modules de spécialisation] Programme GdP7
[Modules de spécialisation] Programme GdP7[Modules de spécialisation] Programme GdP7
[Modules de spécialisation] Programme GdP7
 
CIO Mag : Les Best Practices Finatech pour la Gestion des Projets TI
CIO Mag : Les Best Practices Finatech pour la Gestion des Projets TICIO Mag : Les Best Practices Finatech pour la Gestion des Projets TI
CIO Mag : Les Best Practices Finatech pour la Gestion des Projets TI
 
La Gestion de Projet.pdf
La Gestion de Projet.pdfLa Gestion de Projet.pdf
La Gestion de Projet.pdf
 
D’un pilotage de projet traditionnel à innovant, quelle marche à suivre ?
D’un pilotage de projet traditionnel à innovant, quelle marche à suivre ?D’un pilotage de projet traditionnel à innovant, quelle marche à suivre ?
D’un pilotage de projet traditionnel à innovant, quelle marche à suivre ?
 
Management de projet slide share
Management de projet slide shareManagement de projet slide share
Management de projet slide share
 
[MOOC GdP] Spécialisations GdP9
[MOOC GdP] Spécialisations GdP9[MOOC GdP] Spécialisations GdP9
[MOOC GdP] Spécialisations GdP9
 
Gestion de projet chapitre 0 ppt projets
Gestion de projet chapitre 0 ppt projetsGestion de projet chapitre 0 ppt projets
Gestion de projet chapitre 0 ppt projets
 
Gestion_de_projet_université.ppt
Gestion_de_projet_université.pptGestion_de_projet_université.ppt
Gestion_de_projet_université.ppt
 
Cours sur les bases de la Gestion_de_projet_université.ppt
Cours sur les bases de la Gestion_de_projet_université.pptCours sur les bases de la Gestion_de_projet_université.ppt
Cours sur les bases de la Gestion_de_projet_université.ppt
 
Support GESPRO-2023-2024.pptx
Support GESPRO-2023-2024.pptxSupport GESPRO-2023-2024.pptx
Support GESPRO-2023-2024.pptx
 
Project Management Course Outline
Project Management Course OutlineProject Management Course Outline
Project Management Course Outline
 
Le management projet 2011
Le management projet 2011Le management projet 2011
Le management projet 2011
 
gestion_de_projet_universite.ppt
gestion_de_projet_universite.pptgestion_de_projet_universite.ppt
gestion_de_projet_universite.ppt
 
Conduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & OutilsConduite de projets Web, pilotage & Outils
Conduite de projets Web, pilotage & Outils
 
Comment mettre en place un bureau de projets avec succès !
Comment mettre en place un bureau de projets avec succès !Comment mettre en place un bureau de projets avec succès !
Comment mettre en place un bureau de projets avec succès !
 

Plus de Echecs & Stratégie

Green IT et développement durable
Green IT et développement durableGreen IT et développement durable
Green IT et développement durable
Echecs & Stratégie
 
La Gestion du temps
La Gestion du tempsLa Gestion du temps
La Gestion du temps
Echecs & Stratégie
 
Formation à la Stratégie d'entreprise (Michael Porter, Blue Océan strategy, J...
Formation à la Stratégie d'entreprise (Michael Porter, Blue Océan strategy, J...Formation à la Stratégie d'entreprise (Michael Porter, Blue Océan strategy, J...
Formation à la Stratégie d'entreprise (Michael Porter, Blue Océan strategy, J...
Echecs & Stratégie
 
Formation à la Stratégie d'entreprise
Formation à la Stratégie d'entrepriseFormation à la Stratégie d'entreprise
Formation à la Stratégie d'entreprise
Echecs & Stratégie
 
Cours de Gestion du temps
Cours de Gestion du tempsCours de Gestion du temps
Cours de Gestion du temps
Echecs & Stratégie
 
Initiation aux echecs
Initiation aux echecsInitiation aux echecs
Initiation aux echecs
Echecs & Stratégie
 
Apprendre à jouer aux échecs en 2 heures chrono
Apprendre à jouer aux échecs en 2 heures chronoApprendre à jouer aux échecs en 2 heures chrono
Apprendre à jouer aux échecs en 2 heures chrono
Echecs & Stratégie
 
Cours échecs du débutant au joueur confirmé (II)
Cours échecs du débutant au joueur confirmé (II)Cours échecs du débutant au joueur confirmé (II)
Cours échecs du débutant au joueur confirmé (II)
Echecs & Stratégie
 
Cours de tactique aux echecs
Cours de tactique aux echecsCours de tactique aux echecs
Cours de tactique aux echecs
Echecs & Stratégie
 
Cours d'échecs du débutant au joueur confirmé (modules 1 à 20)
Cours d'échecs du débutant au joueur confirmé (modules 1 à 20)Cours d'échecs du débutant au joueur confirmé (modules 1 à 20)
Cours d'échecs du débutant au joueur confirmé (modules 1 à 20)
Echecs & Stratégie
 
[Vidéos intégrées ] - La prise de décision aux échecs par chess & strategy
[Vidéos intégrées ] - La prise de décision aux échecs  par chess & strategy[Vidéos intégrées ] - La prise de décision aux échecs  par chess & strategy
[Vidéos intégrées ] - La prise de décision aux échecs par chess & strategy
Echecs & Stratégie
 
Cursus adulte débutant chess & strategy
Cursus adulte débutant chess & strategyCursus adulte débutant chess & strategy
Cursus adulte débutant chess & strategy
Echecs & Stratégie
 

Plus de Echecs & Stratégie (12)

Green IT et développement durable
Green IT et développement durableGreen IT et développement durable
Green IT et développement durable
 
La Gestion du temps
La Gestion du tempsLa Gestion du temps
La Gestion du temps
 
Formation à la Stratégie d'entreprise (Michael Porter, Blue Océan strategy, J...
Formation à la Stratégie d'entreprise (Michael Porter, Blue Océan strategy, J...Formation à la Stratégie d'entreprise (Michael Porter, Blue Océan strategy, J...
Formation à la Stratégie d'entreprise (Michael Porter, Blue Océan strategy, J...
 
Formation à la Stratégie d'entreprise
Formation à la Stratégie d'entrepriseFormation à la Stratégie d'entreprise
Formation à la Stratégie d'entreprise
 
Cours de Gestion du temps
Cours de Gestion du tempsCours de Gestion du temps
Cours de Gestion du temps
 
Initiation aux echecs
Initiation aux echecsInitiation aux echecs
Initiation aux echecs
 
Apprendre à jouer aux échecs en 2 heures chrono
Apprendre à jouer aux échecs en 2 heures chronoApprendre à jouer aux échecs en 2 heures chrono
Apprendre à jouer aux échecs en 2 heures chrono
 
Cours échecs du débutant au joueur confirmé (II)
Cours échecs du débutant au joueur confirmé (II)Cours échecs du débutant au joueur confirmé (II)
Cours échecs du débutant au joueur confirmé (II)
 
Cours de tactique aux echecs
Cours de tactique aux echecsCours de tactique aux echecs
Cours de tactique aux echecs
 
Cours d'échecs du débutant au joueur confirmé (modules 1 à 20)
Cours d'échecs du débutant au joueur confirmé (modules 1 à 20)Cours d'échecs du débutant au joueur confirmé (modules 1 à 20)
Cours d'échecs du débutant au joueur confirmé (modules 1 à 20)
 
[Vidéos intégrées ] - La prise de décision aux échecs par chess & strategy
[Vidéos intégrées ] - La prise de décision aux échecs  par chess & strategy[Vidéos intégrées ] - La prise de décision aux échecs  par chess & strategy
[Vidéos intégrées ] - La prise de décision aux échecs par chess & strategy
 
Cursus adulte débutant chess & strategy
Cursus adulte débutant chess & strategyCursus adulte débutant chess & strategy
Cursus adulte débutant chess & strategy
 

Dernier

Chap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdfChap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdf
TimogoTRAORE
 
Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
Friends of African Village Libraries
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
NadineHG
 
1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif
NadineHG
 
Auguste Herbin.pptx Peintre français
Auguste   Herbin.pptx Peintre   françaisAuguste   Herbin.pptx Peintre   français
Auguste Herbin.pptx Peintre français
Txaruka
 
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
Editions La Dondaine
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
Txaruka
 

Dernier (7)

Chap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdfChap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdf
 
Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
 
1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif
 
Auguste Herbin.pptx Peintre français
Auguste   Herbin.pptx Peintre   françaisAuguste   Herbin.pptx Peintre   français
Auguste Herbin.pptx Peintre français
 
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
 

Gestion de Projet

  • 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 La gestion de projets et les compétences requises 10h30 - 11h00 Pause 4 13h30 - 15h00 Les règles pour éviter de faire déraper un projet 11h00 - 12h30 Les outils clés du chef de projet 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 : Retours d’Expérience Quelles sont les qualités d’un bon chef de projet ? Comment entretenir la motivation des équipiers du projet ? 5 Comment réaliser un tableau de bord du projet ? Quelles sont les règles de la relation avec le commanditaire ? Comment bien communiquer ? Comment éviter de faire déraper un projet ?
  • 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 : C’est quoi la gestion de projet ? La gestion de projet en 2 min : https://www.youtube.com/watch?v=KstwnJm4OO0
  • 8. Gestion de projet 8 C’est quoi la gestion de projet ? 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 ?
  • 9. C’est quoi la gestion de projet ? 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. 9Gestion de projet
  • 10. 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. 10Gestion de projet 1 2
  • 11. 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. 11Gestion de projet 3
  • 12. Quelles sont les compétences requises du chef de projet ? 12
  • 13. Gestion de projet 13 Zoom sur le métier de chef de projet La vidéo: https://www.youtube.com/watch?v=NL_B9c7BIhs
  • 14. Quelles sont les compétences requises du chef de projet ? 14 Lister une dizaine de compétences
  • 15. 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 les parties prenantes Un responsable – Il dispose de moyens et d'obligations – Il doit tenir ses objectifs… Gestion de projet 15 Le chef de projet est …
  • 16.  Cadrage 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 16 Les missions du chef de projet sont multiples
  • 17. Gestion de projet 17 Les soft skills 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.
  • 18. Gestion de projet 18 Les compétences du chef de projet = une rose des vents
  • 19. Gestion de projet 19 Les compétences du chef de projet L’outil de la rose des vents 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.
  • 20. Gestion de projet 20 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.
  • 21. Gestion de projet 21 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
  • 22. Gestion de projet 22 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 d’un 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.
  • 23. Quelles sont les compétences à travailler parmi celle citées ? 23
  • 24. Le plan de communication du projet 24
  • 25. Gestion de projet 25 La communication, première compétence du chef de projet Le lien vers la vidéo
  • 26. Gestion de projet 26 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.
  • 27. Gestion de projet 27 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.
  • 28. Gestion de projet 28 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.
  • 29. Gestion de projet 29 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 ?
  • 30. Gestion de projet 30 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.
  • 31. Comment entretenir la motivation des équipiers du projet ? 31
  • 32. Gestion de projet 32 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
  • 33. Gestion de projet 33 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
  • 34. Gestion de projet 34 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
  • 35. Gestion de projet 35 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
  • 36. Gestion de projet 36 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.
  • 37. Gestion de projet 37 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.
  • 38. Quelles sont les règles de la relation avec le commanditaire ? 38
  • 39. Gestion de projet 39 Les règles de la relation avec le commanditaire Vidéo : transmettre la vision du commanditaire à l’équipe projet
  • 40. Gestion de projet 40 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é.
  • 41. Gestion de projet 41 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.
  • 42. Gestion de projet 42 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
  • 43. Gestion de projet 43 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
  • 44. Gestion de projet 44 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.
  • 45. Gestion de projet 45 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
  • 46. Le tableau de bord du projet 46
  • 47. Gestion de projet 47 Le tableau de bord du projet La vidéo
  • 48. Gestion de projet 48 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).
  • 49. Comment éviter de faire déraper un projet ? 49
  • 50. 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. 50Gestion de projet
  • 51. 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. 51
  • 52. 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. 52 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 ?
  • 53. 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. 53
  • 54. 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. 54
  • 55. 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. 55
  • 56. 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. 56
  • 57. 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 ? 57
  • 58. 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 58
  • 59. 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. 59 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.
  • 60. 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. 60 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.
  • 61. 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. 61
  • 62. 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. 62
  • 63. 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. 63
  • 64. 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. 64 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.
  • 65. 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. 65
  • 66. 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. 66 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.
  • 67. 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. 67 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
  • 68. 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 68
  • 69. 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. 69 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 !
  • 70. 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. 70
  • 71. 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. 71
  • 72. 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 ? 72
  • 73. 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. 73
  • 74. 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. 74
  • 75. 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. 75
  • 76. 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. 76 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.
  • 77. 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. 77 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é !
  • 78. 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. 78
  • 79. 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 79
  • 80. 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. 80
  • 81. 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. 81 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.
  • 82. 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. 82 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.
  • 83. 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. 83
  • 84. 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. 84
  • 85. 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. 85 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.
  • 86. 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. 86
  • 87. 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 ... 87
  • 88. 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. 88
  • 89. 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. 89
  • 90. 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. 90 La négociation ne pouvant se faire que sur les moyens d'atteindre les composantes de l'objectif.
  • 91. 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. 91
  • 92. 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. 92
  • 93. 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. 93
  • 94. 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. 94
  • 95. 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. 95
  • 96. Merci de votre attention 96