2/3/2009 - 1 -

LES ECUEILS DE LA GESTION DE PROJET TI ET COMMENT LES

EVITERPMI Montréal

04-FEV-09

2/3/2009 - 2 -

Introduction

Olivier Abécassis, PMP, ITSM

Svetlana Sidenko, PMP, ITSM, MSc (Admin)

IT CHAPTER : formation et consultation

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

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

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

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

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

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

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

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 écartsd’envergure.

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

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

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

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 surl’é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ôledes changements

� Le commanditaire du projet doit signer les Demandes De Changement

5 - Écart d'envergure, absence de contrôle du changement

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

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 nouvellesinitiatives

� 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

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é

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 dansle budget sous la pression des exécutifs

7 - Le budget du projet est sous-estimé

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

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 votreprojet, s’appuyer sur les procédures agrées

8 - Les membres de l'équipe ont d'autres priorités dans l’organisation

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

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

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

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

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

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.

2/3/2009 - 27 -

Déraillement à Paris Montparnasse en 1895Tout ce qui peut aller mal, ira mal

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

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

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 responsable3. Gérer les attentes des utilisateurs en les impliquant le plus tôt possible

dans le projet4. Utiliser l’aide des experts pour identifier les dépendances entre projets5. Etablir une procédure formelle de contrôle des changements pour éviter

des écarts d’envergure6. Etablir une procédure formelle pour suivre l’échéancier et documenter

toutes les décisions importantes de replanification7. 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.

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