1. 2/3/2009 - 1 -
LES ECUEILS DE LA GESTION DE
PROJET TI ET COMMENT LES
EVITER
PMI Montréal
04-FEV-09

2. 2/3/2009 - 2 -
Introduction
Olivier Abécassis, PMP, ITSM
Svetlana Sidenko, PMP, ITSM, MSc (Admin)
IT CHAPTER : formation et consultation

3. 2/3/2009 - 3 -
Les projets TI continuent d’échouer...
Une étude du Groupe Standish :
Seulement 29% des projets TI sont complétés avec succès
Une étude de Dynamic Markets Ltd. datant de 2007 :
62% des projets TI échouent à rencontrer leurs échéanciers
49% souffrent de dépassements budgétaires
47% ont des coûts de maintenance supérieurs aux coûts prévus
41% ne parviennent pas à livrer la valeur attendue

4. 2/3/2009 - 4 -
5%
12%
14%
14%
55%
0% 20% 40% 60%
Mauvais alignement entre les objectifs du business et du
projet
L'équipe de projet perd de son efficacité en ayant trop
de processus à gérer
Les processus de GP sont vus comme du surplus de
gestion
L'équipe de projet ne suit pas les processus de gestion
de projet standards et reproductibles
Manque de support des exécutifs; le sponsor du projet
n'est pas 100% commis aux objectifs, ne comprend que
partiellement le projet et ne s'implique pas activement
PROCESSUS DE GESTION DE PROJET ET METHODOLOGIE
1 - Manque de support des exécutifs

5. 2/3/2009 - 5 -
1 - Manque de support des exécutifs
IMPACT
Peu de chances d’assigner les bonnes ressources
Le projet manque de visibilité au niveau de la compagnie
Peu probable que le projet soit défendu par les éxecutifs
Plus difficile d’engager des équipes cross-fonctionnelles

6. 2/3/2009 - 6 -
SOLUTION / AU DEMARRAGE DU PROJET
Rédiger un sommaire exécutif
Construire un cas d’affaire (ROI)
Avoir un diagramme de GANTT avec des jalons solides
Clarifier le rôle et la responsabilité du commanditaire
SOLUTION / PENDANT L’EXECUTION DU PROJET
Gérer le commanditaire comme une ressource du projet
CONSEIL
Les exécutifs veulent des chiffres, des statuts et pas de surprises
1 - Manque de support des exécutifs

7. 2/3/2009 - 7 -
12%
20%
28%
40%
0% 10% 20% 30% 40%
Processus d'approbation inexistant ou insuffisant
Cas d'affaire peu clair ou peu convaincant
Manque de perfection et de diligence dans les phases
de démarrage de projet
Manque de propriété et de responsabilité d'affaires
PROBLEMES LORS DE L'INITIALISATION DU PROJET
2 - Manque de propriété et de responsabilité
d’affaires

8. 2/3/2009 - 8 -
IMPACT
Glissement des tâches, faible qualité des livrables, conflits
SOLUTION
Définir un tableau RACI
Rendre les tâches VISIBLES aux parties prenantes
Utiliser un mécanisme de communication bien défini
Impliquer l’utilisateur final et le client
Eliminer les excuses !
CONSEIL : Une tâche, un responsable.
2 - Manque de propriété et de responsabilité
d’affaires

9. 2/3/2009 - 9 -
5%
5%
12%
12%
20%
46%
0% 10% 20% 30% 40% 50%
Choix technologiques erronés ou inadéquats
Technologies nouvelles ou changeantes ; manque de
qualifications techniques
Propriétaire de produit peu clair ou peu disponible
Phase de correction des anomalies en fin de projet est
longue et imprévisible
Problèmes d'intégration pendant l'exécution
Manque de participation des utilisateurs (ayant pour
conséquence des problèmes sur la gestion des attentes
PROBLEMES SUR LES BESOINS TECHNIQUES ET FONCTIONNELS
3 - Manque de participation des utilisateurs

10. 2/3/2009 - 10 -
3 - Manque de participation des utilisateurs
IMPACT
Attentes irréalistes sur le comment et le quand de la solution
Ecarts d’envergure
SOLUTION
Impliquer très tôt les usagers
Avoir des experts du sujet (SME) et des représentants des usagers
Définir clairement nos attentes par rapport à la participation des
utilisateurs
Ecrire les spécifications “dans le marbre” pour éviter les écarts
d’envergure.

11. 2/3/2009 - 11 -
2%
17%
20%
24%
37%
0% 5% 10% 15% 20% 25% 30% 35% 40%
Le cédule du projet est
incomplet
Trop peu de temps ou
d'argent alloué
Manque de planification
Manque de compréhension
des besoins
Ne pas voir les dépendances
entre les projets
GESTION DE L'INTEGRATION DU PROJET
4 – Ne pas voir les dépendances entre projets

12. 2/3/2009 - 12 -
IMPACT
Date de fin du projet non réaliste
Manquer l’opportunité d’adresser des problèmes potentiel plus tôt
Effet domino sur le pipeline des projets
SOLUTION
Diagramme de GANTT, chemin critique
Trouver les bons experts du sujet (SME)
Prendre en compte les dépendances inter-projets en phase de
planification
4 – Ne pas voir les dépendances entre projets

13. 2/3/2009 - 13 -
7%
21%
32%
40%
0% 10% 20% 30% 40%
Ne pas tracer les changements à l'envergure du projet
L'envergure du projet est trop vague
Ne pas prendre assez de temps pour définir l'envergure
du projet
Ecart d'envergure, absence de contrôle du changement
GESTION DE L'ENVERGURE DU PROJET
5 - Écart d'envergure, absence de contrôle du
changement

14. 2/3/2009 - 14 -
IMPACT
Le budget du projet explose. Idem pour les délais
SOLUTION
Suivre un processus de Demandes De Changement (DDC) formel :
dès la phase d’initialisation du projet TI
Evaluer les conséquences d’un changement de spécifications sur
l’échéancier, les coûts et les risques
Utiliser une approche par phase : un changement aura moins de
chances d’impacter le développement
Si le changement est incontournable, suivre le processus de contrôle
des changements
Le commanditaire du projet doit signer les Demandes De
Changement
5 - Écart d'envergure, absence de contrôle du
changement

15. 2/3/2009 - 15 -
21%
31%
48%
0% 20% 40% 60%
IT accepte des dates cibles peu raisonnables
Les dates cibles du projet sont ignorées par les
membres de l'équipe de projet
Les projets sont bâclés afin d'accélérer les phases de
développement et d'implémentation
GESTION DU TEMPS DE PROJET
6 - Les projets sont expédiés afin d’accélérer le
développement et l’implémentation

16. 2/3/2009 - 16 -
IMPACT
La qualité est compromise et le budget impacté
Les besoins du client ne sont pas rencontrés
SOLUTION
Tracer et réviser les progrès de manière régulière
Documenter les décisions importantes, les livrables et les jalons
Re-planifier et recéduler pour prendre en compte les nouvelles
initiatives
Emettre une procédure pour mettre à jour l’échéancier
6 - Les projets sont expédiés afin d’accélérer le
développement et l’implémentation

17. 2/3/2009 - 17 -
7%
22%
32%
39%
0% 10% 20% 30% 40%
Dépassement des coûts du projet
Le budget du projet n'est pas géré
Le budget du projet n'est pas géré par le chef de projet
Le budget du projet est sous-estimé
GESTION DES COUTS DU PROJET
7 - Le budget du projet est sous-estimé

18. 2/3/2009 - 18 -
IMPACT
Le projet peut être arrêté
Le projet ne pourra pas faire face à des imprévus
SOLUTION
Impliquer les bons experts lors de l’estimation budgétaire
Allouer suffisamment de contingence dans le budget
Procéder à une analyse profonde de l’environnement technique
Ne PAS accepter de couper à priori dans
le budget sous la pression des exécutifs
7 - Le budget du projet est sous-estimé

19. 2/3/2009 - 19 -
2%
17%
29%
52%
0% 20% 40% 60%
Les projets manquent de chefs de projets expérimentés
Les projets manquent de bonnes ressources avec les
bonnes qualifications
Le personnel des TI n'est pas dédié aux tâches de projet
(difficultés à estimer leur propre disponibilité,
inexactitudes dans l'évaluation de la tâche)
Les membres de l'équipe ont d'autres priorités dans
l'organisation
GESTION DES RESSOURCES HUMAINES DU PROJET
8 - Les membres de l'équipe ont d'autres priorités
dans l’organisation

20. 2/3/2009 - 20 -
IMPACT
Ajoute du stress aux membres de l’équipe
Réduit la productivité et la qualité des livrables
SOLUTION
Négocier avec le directeur fonctionnel
Se mettre d’accord sur la meilleure façon de gérer les confits de
priorité
Si des conflits de priorité viennent affecter la performance de votre
projet, s’appuyer sur les procédures agrées
8 - Les membres de l'équipe ont d'autres priorités
dans l’organisation

21. 2/3/2009 - 21 -
22%
26%
52%
0% 20% 40% 60%
Les essais sont inadéquats
Le développement et l'exécution du plan d'essais sont
considérés comme du temps perdu ou superflu
Les critères de qualité du projet sont mal définis
GESTION DE LA QUALITE DU PROJET
9 - Critères de qualité du projet sont mal définis

22. 2/3/2009 - 22 -
IMPACT
Difficile de prendre les bonnes décisions sur les anomalies
Les premières versions des livrables ne rencontrent pas les standards
de qualité
Du temps et des $ sont perdus à résoudre les mauvais défauts
SOLUTION
Se mettre à priori d’accord sur les critères de succès et les mesures
Mettre en place un système de mesure de la qualité
Adresser la non-qualité immédiatement
Revoir les critères qualité (si nécessaire)
9 - Critères de qualité du projet sont mal définis

23. 2/3/2009 - 23 -
7%
19%
19%
22%
33%
0% 10% 20% 30% 40%
La communication aux "stakeholder" et aux exécutifs
du projet est trop technique (ex : des centaines de
pages de spécs.)
Peu de collaboration, de communication et de travail
d'équipe
Visibilité non satisfaisante des statuts de projet
Prise en compte insuffisante des besoins des
"stakeholder" ; manque de contrôle des attentes
La communication n'a pas été planifiée d'avance
GESTION DE LA COMMUNICATION DU PROJET
10 – La communication n’a pas été planifiée
d’avance

24. 2/3/2009 - 24 -
IMPACT
Même les meilleurs projets, qui délivrent toutes leurs promesses,
peuvent avoir une mauvaise réputation et être perçus comme des
échecs
SOLUTION
Identifier les différentes parties prenantes et définir le type
d’information qui ira le mieux à chaque groupe :
Exécutif / commanditaire
Membres de l’équipe de projet
Clients / utilisateurs
Bureau de projet
Chef de projet – vous-même
10 – La communication n’a pas été planifiée
d’avance

25. 2/3/2009 - 25 -
20%
21%
23%
36%
0% 10% 20% 30% 40%
La stratégie de gestion des risques est mal identifiée au
début du projet
Les risques du projet sont ignorés
Les risques du projet sont mal contrôlés
Les risques ont été mal identifiés au début du projet
GESTION DES RISQUES DU PROJET
11 – Les risques ont été mal identifiés au début du
projet

26. 2/3/2009 - 26 -
Qu’est-ce que la loi de Murphy ?
“S’il y a deux façons ou plus de faire quelque chose,
et qu’une de ces façons peut se terminer en
catastrophe, alors quelqu’un va le faire”
(Edward A. Murphy Jr, 1947)
Tout ce qui peut aller mal, ira mal, au pire moment.

27. 2/3/2009 - 27 -
Déraillement à Paris Montparnasse en 1895
Tout ce qui peut aller mal, ira mal

28. 2/3/2009 - 28 -
Une rôtie et du beurre
Je n’ai jamais eu une tranche de pain,
Particulièrement épaisse et large,
Qui ne soit tombée sur le plancher,
Et toujours sur la face beurrée.
American newspaper in Norwalk, Ohio, 1841

29. 2/3/2009 - 29 -
IMPACT
Retard dans le projet, dépassement des coûts, fin prématurée du
projet
SOLUTION
Séance de remue-méninges avec les parties prenantes pour prédire
les menaces au projet
Focaliser sur la quantité de risques
Enregistrer tous les risques qui ont été mentionnés
Construire un plan de gestion des risques et le maintenir.
11 – Les risques ont été mal identifiés au début du
projet

30. 2/3/2009 - 30 -
Conclusion : comment éviter les écueils les plus
fréquents en projets TI
1. Avoir le support des exécutifs
2. S’assurer de la responsabilité sur le projet : 1 tâche – 1 responsable
3. Gérer les attentes des utilisateurs en les impliquant le plus tôt possible
dans le projet
4. Utiliser l’aide des experts pour identifier les dépendances entre projets
5. Etablir une procédure formelle de contrôle des changements pour éviter
des écarts d’envergure
6. Etablir une procédure formelle pour suivre l’échéancier et documenter
toutes les décisions importantes de replanification
7. Faire un estimé prudent et réaliste du budget avec de la contingence
8. Se mettre d’accord avec les directeurs fonctionnels sur comment gérer
des conflits de priorité sur les ressources du projet
9. Définir clairement les critères de qualité du projet
10. Utiliser et adapter la méthode de communication selon les parties
prenantes du projet
11. Inclure toutes les parties prenantes dans la prédiction des risques du
projet. Maintenir une liste de risques à jour.

31. 2/3/2009 - 31 -
Réferences
Project Management: The 14 Most Common Mistakes IT
Departments Make , July 23 2008, Meridith Levinson, www.cio.com
Project Communication: how to keep your team engaged and
informed. November 13, 2008 | Author: PM Hut
http://www.pmhut.com
How to cheat at IT Project Management , 2005, Susan Snedaker,
www.syngress.com