La gestion de projets informatiques Gestion des technologies

La gestion de projets informatiques Gestion des technologies de l’information – GEST 310 Pascale Vande Velde

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 2

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 3

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 4

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 5

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 6

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 7

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 8

La structure d’un projet • Un projet sera, si nécessaire, divisé en sous projets • La participation des métiers au projet – 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 – 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) 9

Mois Comité IT Sponsor Mois Hebdo & journalier n n Coordination architecture Support fonctionnel et technique Journalier Fixation et suivi de la stratégie et des plans à long terme • Décisions clés sur les gros programmes et les projets transversaux • 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… • Responsable pour la livraison du programme • Rapporte l’état d’avancement au comité de pilotage • Gère les interdépendances entre projets • 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 • 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 Comité de pilotage (*) Program Manager PMO Architecture Journalier Hebdomadaire Project Manager • Project Manager 10

Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée (3) Program manager Architecture Implémentation Package Change Management Interfaces banque 11

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 12

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 : 1 x/mois 13

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 14

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

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 16

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

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 30 -40% Développement et tests unitaires 20% Tests d’intégration 20% Tests d’acceptation 20% Déploiement 0 -10% 18

Tasks Deliverables Conduite du changement Program Management Office • • • Gestion des ressources Suivi du budget Suivi du projet Infrastructure Design • • • 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 Design fonctionnel Design technique Design des processus Plans de tests/stratégie de tests Design de l’architecture Build/Unit test • • • Implementation et Roll Out Test 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 • • Les programmes • • • Les cas de tests Les résultats de tests Validation des tests utilisateurs • • • Organiser les trainings Mettre en place l’environnement de production Effectuer un parallel run Effectuer la migration Assurer le suivi post mise en production Le plan de formations Le plan de support post implémentation 19

Change Infrastructure PMO Design Build Test Roll-out La gestion des environnements • Plusieurs environnements sont nécessaires pour implémenter une nouvelle application • 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 • • – – Un Un ou ou plusieurs environnements de développement de test d’acceptation de production 20

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

Infrastructure Change PMO Design Build Test Roll-out 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 22

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

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

Infrastructure Change PMO Design Build Test Roll-out Niveau d’acceptation du changement La conduite du changement – les moyens à mettre en oeuvre Propriété/Buy in Acceptation Frontière de l’engagement Test § 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 § Développer un plan d’action pour lever les barrières § Communiquer le planning d’implémentation § Mener des formation sur les nouveaux concepts, … § Communiquer à chacun quelles opportunités le projet lui offre § Utiliser les sponsors du projet pour réduire la résistance Compréhension Contact Prise de conscience § Communiquer à chancun l’impact du changement § Utiliser les sponsors et des agents de changement pour délivrer des messages, … Temps Résistance Acceptation/Propriété 25

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

Infrastructure Change PMO Design Build Test Les processus gérés par le PMO Processus de Program management Besoins Gestion du budget Monitoring du taux d’activité sur base du planning et du plan de staffing Change control Contrôle strict sur les augmentations, réductions de périmètre, avec évaluation par rapport au business case, au planning et aux coûts. Ces points doivent être escalés au Comité de Pilotage Délivrables/milestones/ Dependency management Un mécanisme de tracking doit être suivi par tous les project managers Problèmes Une des priorités des project managers est de résoudre les problèmes Réunions de projets Les réunions sont focalisées sur l’état d’avancement (par rapport au budget, au planning, aux délivrables), les problèmes et le change control Qualité Des revues de qualité sont organisées afin de vérifier que le projet est géré selon de bonnes règles de gestion de projet Gestion des ressources Besoin d’anticiper les besoins en ressources et allocation au bon moment aux différents sous projets Risques Les risques doivent être bien documentés et escalés systématiquement au comité de pilotage Suivi du temps passé Tout membre du projet doit rapporter son temps avec un niveau de détail suffisant que pour assurer un bon contôle financier du projet Gestion du planning Utilisation d’un outil de planning commun pour tous les sous projets. Les planning sont gérés par chaque sous projet. Tous les plannings alimentent un programme commun utilisé pour le suivi budgétaire 27 Roll-out

Infrastructure Change PMO Design Build Test Roll-out 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 n Spécifications fonctionnelles – Nombre de fonctions business impactées n Complexité métier – – – # employés et utilisateurs Degré de changement des processus Qualité des données mainframe n Software “Fit” – Nombre de modifications attendues/extensions n Technical “Fit” – Existence d’un environnement technique approprié n Capacité de la société à – – 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 accepter le changement n Intégration et effort de conversion 28

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

Infrastructure Change PMO 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 partie Exemple de montée en charge 30 Roll-out

Infrastructure Change PMO Design Build Test Roll-out 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 31

Infrastructure Change PMO 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. 32 Roll-out

Infrastructure Change PMO Design Build Test Roll-out 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 33

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

Infrastructure Change PMO Design Build Test Roll-out 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 35

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

Infrastructure Change PMO Design Build Test Roll-out 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 • • 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 • Exemple de spécifications techniques – – – Sur base d’une maquette Sur base d’un prototype Sur base d’une description détaillée – – – 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 – – Format des messages Mode de transmission des messages (synchrone, asynchrone) 37

Infrastructure Change PMO 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) 38 Roll-out

Infrastructure Change PMO Design Build Test Roll-out 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 Source des erreurs On découvre que le design a été mal fait pendant les tests … Découverte des erreurs 40% - 60% Besoins utilisateurs Design tech & funct 10% - 20% - 40% Programmation Tests unitaires 10% - 20% Tests d’intégration d’acceptance Maintenance Tests d’intégration d’acceptance 20% - 50% Maintenance 40% - 60% 39

Infrastructure Change PMO Design Build Test Roll-out 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 • Avantages – 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 – 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 40

Infrastructure Change PMO 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 41 Roll-out

Infrastructure Change PMO 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 42 Roll-out

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

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

Infrastructure Change PMO 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 45 Roll-out

Infrastructure Change PMO Design Build Test 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 46