La gestion de projets informatiques

1. La gestion de projets informatiques Gestion des technologies de l’information – GEST310 Pascale Vande Velde

2. Agenda • Introduction • Structure d’un projet • Gouvernance de projets • Les grandes phases d’un projet d’implémentation • La conduite du changement • Le Program Management Office • Le release management • La conception • Le développement • Les tests • Le roll out

3. Introduction • Un projet a pour objectif de mener à bien le développement d’une nouvelle application ou l’adaptation d’une application existante • Un projet est caractérisé par : • Un périmètre – quels sont les besoins clients auxquels on doit répondre • Un deadline – le projet doit être terminé à une date fixe • Des délivrables – les produits finis du projet • Un planning indiquant quand chaque produit fini sera livré et comment les activités et donc la charge de travail sera répartie dans le temps • Des ressources dédiées partiellement ou totalement au projet • Une structure de gouvernance

4. Introduction • Typologie de projets • < 50 jours hommes, maintenance • 50 < X < 500 jours hommes – petit projet • 500 < X < 3,000 jours hommes – projet moyen • X > 3,000 jours hommes – large projet • X > 20,000 jours hommes – mega projet

5. Exemple de planning d’un programme • Le macro planning montre l’étalement des releases, la charge hommes liée à chaque release et les jalons principaux (milestones) du programme

6. Exemple de planning détaillé • Le planning reprend les activités principales, sous-activités, délivrables, la fréquence des comités de pilotage

7. Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (1) • Release 1 : alimentation du package par des données back offices (titres, espèces, comptes à terme) et production d’un rapport de gestion clients • Release 2 : mise en place des fonctionnalités de gestion de portefeuille (calculs de return, gestion des portefeuilles contre stratégies et contraintes, benchmarking, passages d’ordres....), roll out du package sur 50 utilisateurs répartis sur 5 agences • Release 3 : enrichissement du flux d’ordres, roll out du package sur 200 utilisateurs répartis dans 20 agences • Planning • Release 1 : juin 2003 à août 2004 • Release 2 : septembre 2004 à juillet 2005 • Release 3 : juillet 2005 à fin 2005

8. Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (2) • Quelques chiffres • Nombre d’utilisateurs : 250 • Nombre de portefeuilles : 40,000 • Actifs en gestion : 40 milliards EUR • Parts de marché private banking NL : 30% • Coûts release 1 – 10,5 MEUR • Coûts licences : 1,5 MEUR • Coûts implémentation : 7 MEUR (+/- 7,000 jours hommes, 35 personnes sur un an) • Coûts infrastructure : 2 MEUR • Coûts release 2 – 8,5 MEUR • Coûts de licence : 0,5 MEUR • Coûts d’implémentation : 6 MEUR (+/- 6,000 jours hommes) • Coûts infrastructure : 2 MEUR • Coûts cumulés release 1 + 2 : 19 MEUR

9. La structure d’un projet • Un projet sera, si nécessaire, divisé en sous projets • Chaque sous projet sera géré par un project manager • Les project managers rapporteront à un program manager, en charge de l’ensemble du projet • Le program manager rapportera l’état d’avancement du projet à un comité de pilotage • Pour de gros projets, il existe un Program Management Office, en charge du suivi financier et administratif du projet • La participation des métiers au projet • Le sponsor du projet est, en général, un directeur du métier concerné • Via un co management d’un projet par l’IT et le métier concerné • Via une participation partielle ou à temps plein de représentants du métier dans le projet (définition des spécifications, validation des prototypes, tests, validation des tests)

10. Fixation et suivi de la stratégie et des plans à long terme • Décisions clés sur les gros programmes et les projets transversaux Comité IT Mois • Sponsorship & propriété des projets/programmes • Suivi de l’état d’avancement du projet et prise de décision en matière de délivrables, périmètres, problèmes, ressources, etc… Sponsor Comité de pilotage (*) Mois • Responsable pour la livraison du programme • Rapporte l’état d’avancement au comité de pilotage • Gère les interdépendances entre projets Program Manager Hebdo & journalier • Coordination architecture • Support fonctionnel et technique Architecture PMO • Définit les processus et outils nécessaires pour la gestion du programme et des projets • Aide/accompagne le program manager et les project managers • Assure la coordination et communication transversale Journalier Hebdomadaire • Responsable pour le planning et la livraison des projets • Rapporte le statut des délivrables, le planning, les risques et problèmes au program manager Project Manager Project Manager Project Manager Journalier

11. Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (3)

12. Gouvernance de projet • Tout projet doit avoir un comité de pilotage approprié • Une structure claire de projet et de gouvernance est nécessaire : • Réalisation du projet avec succès • Participation de toutes les parties impliquées • Définition claire des rôles et responsabilités des personnes impliquées dans le projet et dans le comité de pilotage • Contrôle et suivi étroit du progrès du projet • Capacités à mitiger les risques • Mécanismes clairs d’escalation des problèmes

13. Le rôle des membres du comité de pilotage • Rôle • Gardien de la vision et des objectifs du projet • Gère la communication sur le projet vis-à-vis de tiers • Suit le planning et les délivrables, pas les processus • Responsabilités • Règle les problèmes organisationnels et de ressources • Gère l’allocation des ressources et les dépendances entre projets • Est responsable de la communication au sein et en-dehors du projet • Valide les délivrables • Gère le périmètre et mitige les risques • Fréquence de réunion : 1x/mois

14. Le rôle du program manager • Rôle • Gardien du planning du projet • Assure la gestion du projet au jour le jour • Gère le statut du projet • Escale à temps et de manière appropriée les problèmes au comité de pilotage • Responsabilités • Coordonne les parties et s’assure de la réalisation du projet à temps • Gère, planifie les ressources • Gère les aspects financiers du projet • Adhère aux best practices, méthodologies et outils de développement • Gère le périmètre et les risques

15. Gouvernance du projet Définir les objectifs Résoudre les problèmes Comité de pilotage Valider les objectifs Gérer le périmètre en ligne avec attentes métiers Program Mgmt Définir le périmètre du programme Résoudre/escaler les problèmes Valider le périmètre du programme Gérer le périmètre du programme Project Management Définir le périmètre du projet Résoudre/escaler les problèmes Exécution du projet Valider le périmètre du projet Gérer le périmètre du projet

16. Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (4) • Implémentation d’un outil de gestion de portefeuille dans une banque privée, n’ayant pas d’IT mais se reposant sur les systèmes back office de sa maison-mère (titres, espèces, money markets, administration clients) • Les interdépendances avec les back offices sont très fortes étant donné la nécessité d’interfacer le PM package avec ces back offices pour remonter les clients, portefeuilles, transactions journalièrement • Les interdépendances avec le département infrastructure de la maison-mère sont également très fortes; étant donné que l’infrastructure du package devra être installée et gérée par ce département • Le comité de pilotage incluait • Le COO de la banque privée • Le Chief Investment Officer de la banque privée • Le directeur du département infrastructure IT • Les responsables métiers et IT de chaque back office

17. Titres PMS Rapports clients Espèces Clients Responsabilité du projet Responsabilité des projets d’extraction Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (5) Maison-mère Banque Privée

18. Les grandes phases d’un projet d’implémentation • Tout projet d’implémentation suit la même séquence d’activités Comité de pilotage Conduite du changement PMO Infrastructure Demande PROJECT Design fonctionnel et technique Développement et tests unitaires Tests d’intégration Déploiement Tests d’acceptation 20% 20% 0-10% 30-40% 20%

19. Conduite du changement Program Management Office • Suivi du budget • Suivi du projet Infrastructure Implementation et Roll Out • Gestion des ressources Design Build/Unit test Test • Etablir le design fonctionnel de la solution • Etablir le design technique • Définir les éléments à développer (formats, écrans,….) • Définir l’approche de test et l’architecture technique • Définir le contenu des formations • Définir les nouveaux processus, l’impact sur des processus existants • Mettre en place l’environnement de développement • Développer les interfaces • Développer l’application • Effectuer du nettoyage de données • Effectuer les tests unitaires de l’interface et de l’application • Mettre en place les environnements de test • Effectuer des tests d’intégration • Effectuer les tests d’acceptation • Mettre en place les environnements de d’acceptation • Organiser les trainings • Mettre en place l’environnement de production • Effectuer un parallel run • Effectuer la migration • Assurer le suivi post mise en production Tasks • Les cas de tests • Les résultats de tests • Validation des tests utilisateurs • Le plan de formations • Le plan de support post implémentation • Les programmes • Design fonctionnel • Design technique • Design des processus • Plans de tests/stratégie de tests • Design de l’architecture Deliverables

20. Change Infrastructure PMO Roll-out Design Build Test La gestion des environnements • Plusieurs environnements sont nécessaires pour implémenter une nouvelle application • Un ou plusieurs environnements de développement • Un ou plusieurs environnements de test • Un ou plusieurs environnements d’acceptation • Un ou plusieurs environnements de production • Chaque environnement supporte une version de l’application (application, base de données, interfaces..) • Plusieurs environnements peuvent se trouver sur la même machine physique. En pratique, pour des applications lourdes, une machine est utilisée par environnement • L’installation d’une machine prend du temps (+/- 2 mois) et doit donc être bien planifiée. On commence d’abord par installer la machine de développement • La gestion des environnements de développement et de tests est, en général, effectuée par le projet • La gestion des environnements d’acceptation et de production est, en générale, effectuée par le département qui “hostera” les machines en production

21. Change Infrastructure PMO Roll-out Design Build Test La gestion des environnements Projet Production TEST DEV UAT PROD Migration d’un package de développement Migration d’un package de développement Migration d’un package de développement Maître pour les développements Correction d’un bug

22. Infrastructure Change PMO Roll-out Design Build Test La conduite du changement • Les facteurs d’échec : • Un manque de communication ou une communication inappropriée • Un manque d’implication du client dans le projet. Le projet est réalisé par l’IT ou par une partie externe • Manque de support du management pour l’utilisation du système • Mismatch au niveau des attentes utilisateurs • L’organisation n’est pas prête/revue pour la mise en production de l’application • Les rôles, les compétences des utilisateurs ne sont pas adaptés à la nouvelle manière de fonctionner • Manque de prise de conscience des avantages du nouveau système • Trop peu de formations ou des formations inappropriées

23. Infrastructure Change PMO Roll-out Design Build Test La conduite du changement – d’une attitude négative Efforts pour regagner le contrôle de la situation Acceptation du changement, réalisme Bargaining Minimise l’impact du changement Actif Rejet réaction défensive face à une situation inacceptable Test, essaye de nouvelles choses Immobilisation crainte, confusion Passif Dépression frustration, sentiment d’échec Temps Source: Kuebler-Ross, 1969: Conner, 1992 Changement négatif Changement positif

24. “ Comment puis-je convaincre d’autres de changer ? ” Propriété/Buy in “Comment cela impacte-t-il mon travail journalier ?” Acceptation Test “Semble bien sur papier, mais nous changeons tout le temps. Quand puis-je l’essayer ?” Compréhension “Qu’est-ce que cette nouvelle organisation signifie pour moi ?? ” Prise de conscience “Pourquoi remplace-t-on un bon système ?” Contact “De quoi s’agit-il ?” Infrastructure Change PMO Roll-out Design Build Test La conduite du changement – à une attitude positive Frontière de l’engagement Niveau d’acceptation du changement Temps Acceptation/Propriété Résistance

25. Infrastructure Change PMO Roll-out Design Build Test La conduite du changement – les moyens à mettre en oeuvre • Implémenter des formations centrées sur l’utilisation à long terme du système • Communiquer les résultats du changement • Revoir les bonus, etc… en fonction des changements Propriété/Buy in Acceptation • Développer un plan d’action pour lever les barrières • Communiquer le planning d’implémentation • Mener des formation sur les nouveaux concepts, … Frontière de l’engagement Niveau d’acceptation du changement Test • Communiquer à chacun quelles opportunités le projet lui offre • Utiliser les sponsors du projet pour réduire la résistance Compréhension • Communiquer à chancun l’impact du changement • Utiliser les sponsors et des agents de changement pour délivrer des messages, … Prise de conscience Contact Temps Acceptation/Propriété Résistance

26. Infrastructure Change PMO Roll-out Design Build Test Les activités d’un PMO 12. Communication 2. Gère le périmètre 11. Coordination du changement 3. Gère les risques Suivi du périmètre Rapporte l’état d’avancement 10. Coordination avec Architecture Identifie les risques 4. Gestion financière et business case 1. Programme tracking & reporting Follow-up sur base de critères de qualité Fournit les données pour les budgets et calcul des coûts 9. Quality management Suivi de l’allocation des ressources Planning définit le contenu des releases 5. Gestion des ressources 8. Gestion des contrats 7. Coordination avec les achats 6. Gestion des releases

27. Infrastructure Change PMO Roll-out Design Build Test Les processus gérés par le PMO

28. Infrastructure Change PMO Roll-out Design Build Test L’estimation de l’effort • L’estimation de l’effort est une activité itérative. Plus l’incertitude diminue, meilleure est l’estimation Facteurs Base • Spécifications fonctionnelles • Complexité métier • Software “Fit” • Technical “Fit” • Capacité de la société à accepter le changement • Intégration et effort de conversion • Nombre de fonctions business impactées • # employés et utilisateurs • Degré de changement des processus • Qualité des données mainframe • Nombre de modifications attendues/extensions • Existence d’un environnement technique approprié • Expérience avec les changements passés • Processus de prise de décision • Sponsoring du projet • Résistance au changement • # interfaces & conversions • Complexité de l’ integration • Approche de conversion

29. Processus d’estimation itératif Infrastructure Change PMO Roll-out Design Build Test L’estimation de l’effort Activité Base d’estimation Conception du modèle opératoire # de pratiques métiers Conception des processus métiers # de conversions (manuel / auto) Configuration de l’application & Prototype avec utilisateurs Estimation d’implémentation # d’interfaces entrantes Spécifications fonctionnelles # d’interfaces sortantes Développement & Test Equipe de support technique # de rapports • Approche bottom -up • Charge de travail/ état du projet • Basé sur des benchmarks, points de références Communication et Formation # de modules Plan et exécution de tests systèmes Taille approx de l’équipe Planning de roll-out et exécution Gestion du projet Durée du projet

30. Infrastructure Change PMO Roll-out Design Build Test Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (6) • Estimation de la charge de travail par partie • Exemple de montée en charge

31. Infrastructure Change PMO Roll-out Design Build Test Outils - Le suivi financier de projets • Il est important de pouvoir suivre le coût du projet par rapport à un budget initial (“baseline”) et de justifier les écarts

32. Infrastructure Change PMO Roll-out Design Build Test Outils - Les rapports d’avancement • Rapporter de manière synthétique l’état d’avancement, les risques, les problèmes....Identification des délivrables clés réalisés.

33. Infrastructure Change PMO Roll-out Design Build Test Outils – Le suivi des ressources (time reports) • Il est important de tracker le nombre d’heures passées sur le projet; ce coût étant le principal coût d’un projet d’implémentation • Chacun rapporte ses heures consommées dans un time report • Ceci est utilisé pour le suivi financier du projet, la facturation du projet et éventuellement, le paiement d’heures supplémentaires

34. Infrastructure Change PMO Roll-out Design Build Test Outils – Le suivi des ressources (time reports)

35. Infrastructure Change PMO Roll-out Design Build Test La gestion des “change requests” • Le périmètre est fixé avant le démarrage du projet dans une phase de préparation, cadrage du projet • Il est fréquent que, de nouveaux besoins soient exprimés en cours de projet. • Ceux-ci influencent la charge de travail totale du projet et peuvent mettre la date de livraison en péril. D’où l’importance pour un program manager de : • Bien qualifier chaque change request (un change request trop lourd doit être repoussé dans une release ultérieure) • Suivre de manière spécifique les change requests (état d’avancement, charge de travail) • Faire valider l’inclusion de change requests dans le périmètre du projet par le comité de pilotage

36. Infrastructure Change PMO Roll-out Design Build Test La gestion des “change requests” • Illustration d’un rapport de suivi de l’état d’avancement

37. Infrastructure Change PMO Roll-out Design Build Test Le design (spécifications) • Les spécifications détaillent les besoins métiers à un niveau suffisament détaillé que pour être non interprétables pour le développement de ces spécifications • Les spécifications détaillent les besoins métiers par rapport au système-cible • Sur base d’une maquette • Sur base d’un prototype • Sur base d’une description détaillée • Les spécifications doivent être formellement validées par le responsable du projet métiers • Exemple de spécifications fonctionnelles pour des passages d’ordres • Ecrans de passage d’ordres • Listes d’ordres • Mécanismes de validation des ordres • Le flux des ordres • Le calcul estimatif des frais de transactions • Exemple de spécifications techniques • Format des messages • Mode de transmission des messages (synchrone, asynchrone)

38. Infrastructure Change PMO Roll-out Design Build Test Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (7) • Exemple de design de calcul de performance (basé sur un prototypage) • Exemple de design de rapport de gestion (basé sur une maquette)

39. Infrastructure Change PMO Roll-out Design Build Test L’importance du design Un mauvais design va générer beaucoup de travail en développement (re coding) après les tests et accroître les coûts de développement du projet 40% - 60% 20% - 40% 10% - 20% Source des erreurs Besoins utilisateurs Design tech & funct Programmation Tests unitaires Tests d’intégration Tests d’acceptance Maintenance On découvre que le design a été mal fait pendant les tests … Besoins utilisateurs Design tech & funct Programmation Tests unitaires Tests d’intégration Tests d’acceptance Maintenance Découverte des erreurs 10% - 20% 20% - 50% 40% - 60%

40. Infrastructure Change PMO Roll-out Design Build Test Le prototypage • Méthode itérative pour spécifier et développer • Applicable principalement pour des “packages” • Sur base d’une première collecte des besoins, un prototype est développé et passé en revue avec les utilisateurs • Prérequis • Une bonne anticipation des besoins métiers (expertise) • Des utilisateurs raisonnables – le prototype doit permettre de valider les spécifications et non pas introduire une longue liste de modifications • Avantages • Collecter les demandes de modifications pendant le design et non pendant le testing • Développement en parallèle avec les spécifications • Cadrer les spécifications – éviter le syndrôme de la page blanche (éviter des développements lourds sur des packages). Utiliser des configurations prédéfinies

41. Infrastructure Change PMO Roll-out Design Build Test Le développement • Se baser sur des configurations existantes (packages) • Centraliser les configurations dans un fichier • Réinitialisation des développements • Baseline management – retour à une version précédente aisé • Versioning aisé • Version : état du développement • Conservation des versions précédentes • Documentation des développements

42. Infrastructure Change PMO Roll-out Design Build Test Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (8) • Exemple d’un fichier de développement • Exemple d’un inventaire de développement

43. Infrastructure Change PMO Roll-out Design Build Test Les tests • L’objectif de la phase de test est de valider que les spécifications ont correctement été implémentées • Phases de test principales • Tests unitaires • Tests réalisés par le développeur • Tests de chaque élément de développement • Tests systèmes • Tests réalisés par le développeur • Tests de compatibilité de blocs de développement dans un même environnement • Tests d’intégration • Tests réalisés par une équipe de test projet • Déroulement de jeux de tests fonctionnels • Tests d’acceptation • Tests réalisés par les utilisateurs • Déroulement, une seconde fois, des jeux de tests fonctionnels • Validation formelle par le responsable du projet de la mise en production

44. Infrastructure Change PMO Roll-out Design Build Test Les activités de tests Test planning/Test Management Mise en place des environnements de tests Définition de l’approche de tests Plans de tests Préparation des tests Exécution des tests • Objectifs • Périmètre • Risques • Ressources • Besoins d’environnement • Metrics • Critères d’acceptation • Points de référence • Planning • Conditions de tests • Cycles de tests • Outils de tracking d’erreurs • Jeux de tests • Exécution des jeux de tests

45. Infrastructure Change PMO Roll-out Design Build Test Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (8) • Périmètre • Critères d’acceptation • Points de référence • Tracking sheet

46. Infrastructure Change PMO Test Design Build Roll out Le roll out • Le roll out est la mise en production d’une release. Il est conditionné à l’approbation du métier (sur base des tests d’acceptation) • Le roll out doit être accompagné • D’un plan de formation des utilisateurs • D’un accompagnement de l’équipe projet pendant les premiers mois de mise en production • Résolution des problèmes • Accompagnement utilisateurs • On peut également avoir un “parallel run” avant une mise en production effective. Les utilisateurs utilisent deux systèmes en parallèle (l’ancien et le nouveau). Ils effectuent toutes leurs actions quotidiennes sur le système. Une fois que le parallel run est validé par les utilisateurs, l’application peut être mise en production • Procédure lourde (production like) • Allonge la période de test mais réduit le risque de problèmes en production