Ecueils de la gestion de projets ti francais v1.0

  • 492 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
492
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
59
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 2/3/2009 - 1 -LES ECUEILS DE LA GESTION DEPROJET TI ET COMMENT LESEVITERPMI Montréal04-FEV-09
  • 2. 2/3/2009 - 2 -IntroductionOlivier Abécassis, PMP, ITSMSvetlana 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èsUne étude de Dynamic Markets Ltd. datant de 2007 :62% des projets TI échouent à rencontrer leurs échéanciers49% souffrent de dépassements budgétaires47% ont des coûts de maintenance supérieurs aux coûts prévus41% 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 duprojetLéquipe de projet perd de son efficacité en ayant tropde processus à gérerLes processus de GP sont vus comme du surplus degestionLéquipe de projet ne suit pas les processus de gestionde projet standards et reproductiblesManque de support des exécutifs; le sponsor du projetnest pas 100% commis aux objectifs, ne comprend quepartiellement le projet et ne simplique pas activementPROCESSUS DE GESTION DE PROJET ET METHODOLOGIE1 - Manque de support des exécutifs
  • 5. 2/3/2009 - 5 -1 - Manque de support des exécutifsIMPACTPeu de chances d’assigner les bonnes ressourcesLe projet manque de visibilité au niveau de la compagniePeu probable que le projet soit défendu par les éxecutifsPlus difficile d’engager des équipes cross-fonctionnelles
  • 6. 2/3/2009 - 6 -SOLUTION / AU DEMARRAGE DU PROJETRédiger un sommaire exécutifConstruire un cas d’affaire (ROI)Avoir un diagramme de GANTT avec des jalons solidesClarifier le rôle et la responsabilité du commanditaireSOLUTION / PENDANT L’EXECUTION DU PROJETGérer le commanditaire comme une ressource du projetCONSEILLes exécutifs veulent des chiffres, des statuts et pas de surprises1 - Manque de support des exécutifs
  • 7. 2/3/2009 - 7 -12%20%28%40%0% 10% 20% 30% 40%Processus dapprobation inexistant ou insuffisantCas daffaire peu clair ou peu convaincantManque de perfection et de diligence dans les phasesde démarrage de projetManque de propriété et de responsabilité daffairesPROBLEMES LORS DE LINITIALISATION DU PROJET2 - Manque de propriété et de responsabilitéd’affaires
  • 8. 2/3/2009 - 8 -IMPACTGlissement des tâches, faible qualité des livrables, conflitsSOLUTIONDéfinir un tableau RACIRendre les tâches VISIBLES aux parties prenantesUtiliser un mécanisme de communication bien définiImpliquer l’utilisateur final et le clientEliminer 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équatsTechnologies nouvelles ou changeantes ; manque dequalifications techniquesPropriétaire de produit peu clair ou peu disponiblePhase de correction des anomalies en fin de projet estlongue et imprévisibleProblèmes dintégration pendant lexécutionManque de participation des utilisateurs (ayant pourconséquence des problèmes sur la gestion des attentesPROBLEMES SUR LES BESOINS TECHNIQUES ET FONCTIONNELS3 - Manque de participation des utilisateurs
  • 10. 2/3/2009 - 10 -3 - Manque de participation des utilisateursIMPACTAttentes irréalistes sur le comment et le quand de la solutionEcarts d’envergureSOLUTIONImpliquer très tôt les usagersAvoir des experts du sujet (SME) et des représentants des usagersDéfinir clairement nos attentes par rapport à la participation desutilisateursEcrire les spécifications “dans le marbre” pour éviter les écartsd’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 estincompletTrop peu de temps oudargent allouéManque de planificationManque de compréhensiondes besoinsNe pas voir les dépendancesentre les projetsGESTION DE LINTEGRATION DU PROJET4 – Ne pas voir les dépendances entre projets
  • 12. 2/3/2009 - 12 -IMPACTDate de fin du projet non réalisteManquer l’opportunité d’adresser des problèmes potentiel plus tôtEffet domino sur le pipeline des projetsSOLUTIONDiagramme de GANTT, chemin critiqueTrouver les bons experts du sujet (SME)Prendre en compte les dépendances inter-projets en phase deplanification4 – 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 à lenvergure du projetLenvergure du projet est trop vagueNe pas prendre assez de temps pour définir lenverguredu projetEcart denvergure, absence de contrôle du changementGESTION DE LENVERGURE DU PROJET5 - Écart denvergure, absence de contrôle duchangement
  • 14. 2/3/2009 - 14 -IMPACTLe budget du projet explose. Idem pour les délaisSOLUTIONSuivre un processus de Demandes De Changement (DDC) formel :dès la phase d’initialisation du projet TIEvaluer les conséquences d’un changement de spécifications surl’échéancier, les coûts et les risquesUtiliser une approche par phase : un changement aura moins dechances d’impacter le développementSi le changement est incontournable, suivre le processus de contrôledes changementsLe commanditaire du projet doit signer les Demandes DeChangement5 - Écart denvergure, absence de contrôle duchangement
  • 15. 2/3/2009 - 15 -21%31%48%0% 20% 40% 60%IT accepte des dates cibles peu raisonnablesLes dates cibles du projet sont ignorées par lesmembres de léquipe de projetLes projets sont bâclés afin daccélérer les phases dedéveloppement et dimplémentationGESTION DU TEMPS DE PROJET6 - Les projets sont expédiés afin d’accélérer ledéveloppement et l’implémentation
  • 16. 2/3/2009 - 16 -IMPACTLa qualité est compromise et le budget impactéLes besoins du client ne sont pas rencontrésSOLUTIONTracer et réviser les progrès de manière régulièreDocumenter les décisions importantes, les livrables et les jalonsRe-planifier et recéduler pour prendre en compte les nouvellesinitiativesEmettre une procédure pour mettre à jour l’échéancier6 - Les projets sont expédiés afin d’accélérer ledé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 projetLe budget du projet nest pas géréLe budget du projet nest pas géré par le chef de projetLe budget du projet est sous-estiméGESTION DES COUTS DU PROJET7 - Le budget du projet est sous-estimé
  • 18. 2/3/2009 - 18 -IMPACTLe projet peut être arrêtéLe projet ne pourra pas faire face à des imprévusSOLUTIONImpliquer les bons experts lors de l’estimation budgétaireAllouer suffisamment de contingence dans le budgetProcéder à une analyse profonde de l’environnement techniqueNe PAS accepter de couper à priori dansle budget sous la pression des exécutifs7 - 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ésLes projets manquent de bonnes ressources avec lesbonnes qualificationsLe personnel des TI nest 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 dautres priorités danslorganisationGESTION DES RESSOURCES HUMAINES DU PROJET8 - Les membres de léquipe ont dautres prioritésdans l’organisation
  • 20. 2/3/2009 - 20 -IMPACTAjoute du stress aux membres de l’équipeRéduit la productivité et la qualité des livrablesSOLUTIONNégocier avec le directeur fonctionnelSe mettre d’accord sur la meilleure façon de gérer les confits deprioritéSi des conflits de priorité viennent affecter la performance de votreprojet, s’appuyer sur les procédures agrées8 - Les membres de léquipe ont dautres prioritésdans l’organisation
  • 21. 2/3/2009 - 21 -22%26%52%0% 20% 40% 60%Les essais sont inadéquatsLe développement et lexécution du plan dessais sontconsidérés comme du temps perdu ou superfluLes critères de qualité du projet sont mal définisGESTION DE LA QUALITE DU PROJET9 - Critères de qualité du projet sont mal définis
  • 22. 2/3/2009 - 22 -IMPACTDifficile de prendre les bonnes décisions sur les anomaliesLes premières versions des livrables ne rencontrent pas les standardsde qualitéDu temps et des $ sont perdus à résoudre les mauvais défautsSOLUTIONSe mettre à priori d’accord sur les critères de succès et les mesuresMettre en place un système de mesure de la qualitéAdresser la non-qualité immédiatementRevoir 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écutifsdu projet est trop technique (ex : des centaines depages de spécs.)Peu de collaboration, de communication et de travaildéquipeVisibilité non satisfaisante des statuts de projetPrise en compte insuffisante des besoins des"stakeholder" ; manque de contrôle des attentesLa communication na pas été planifiée davanceGESTION DE LA COMMUNICATION DU PROJET10 – La communication n’a pas été planifiéed’avance
  • 24. 2/3/2009 - 24 -IMPACTMême les meilleurs projets, qui délivrent toutes leurs promesses,peuvent avoir une mauvaise réputation et être perçus comme deséchecsSOLUTIONIdentifier les différentes parties prenantes et définir le typed’information qui ira le mieux à chaque groupe :Exécutif / commanditaireMembres de l’équipe de projetClients / utilisateursBureau de projetChef de projet – vous-même10 – La communication n’a pas été planifiéed’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 audébut du projetLes risques du projet sont ignorésLes risques du projet sont mal contrôlésLes risques ont été mal identifiés au début du projetGESTION DES RISQUES DU PROJET11 – Les risques ont été mal identifiés au début duprojet
  • 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 encatastrophe, 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 1895Tout ce qui peut aller mal, ira mal
  • 28. 2/3/2009 - 28 -Une rôtie et du beurreJe 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 -IMPACTRetard dans le projet, dépassement des coûts, fin prématurée duprojetSOLUTIONSéance de remue-méninges avec les parties prenantes pour prédireles menaces au projetFocaliser sur la quantité de risquesEnregistrer tous les risques qui ont été mentionnésConstruire un plan de gestion des risques et le maintenir.11 – Les risques ont été mal identifiés au début duprojet
  • 30. 2/3/2009 - 30 -Conclusion : comment éviter les écueils les plusfréquents en projets TI1. Avoir le support des exécutifs2. 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 possibledans 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 éviterdes écarts d’envergure6. Etablir une procédure formelle pour suivre l’échéancier et documentertoutes les décisions importantes de replanification7. Faire un estimé prudent et réaliste du budget avec de la contingence8. Se mettre d’accord avec les directeurs fonctionnels sur comment gérerdes conflits de priorité sur les ressources du projet9. Définir clairement les critères de qualité du projet10. Utiliser et adapter la méthode de communication selon les partiesprenantes du projet11. Inclure toutes les parties prenantes dans la prédiction des risques duprojet. Maintenir une liste de risques à jour.
  • 31. 2/3/2009 - 31 -RéferencesProject Management: The 14 Most Common Mistakes ITDepartments Make , July 23 2008, Meridith Levinson, www.cio.comProject Communication: how to keep your team engaged andinformed. November 13, 2008 | Author: PM Huthttp://www.pmhut.comHow to cheat at IT Project Management , 2005, Susan Snedaker,www.syngress.com