Introduction à la Gestion de Projet

(cid:1) l'organisation méthodologique mise en œuvre pour faire en sorte que l'ouvrage réalisé par le maître d'œuvre réponde aux attentes du maître d'ouvrage et qu'il soit livré dans les conditions de coût et de délai prévus initialement.

Approche Classique

Définitions (3/7)

26

Dans une petite/moyenne structure c’est la même

personne.

Approche Classique

Définitions (4/7)

27

(cid:1) Cahier des charges : CDC (specifications)

(cid:1) document qui permet de formaliser avec précision le besoin du

demandeur

(cid:1) Durée ou délai (duration, delay)

(cid:1) différence entre date de fin et date de début du projet (cid:1) Analyse des Risques (risk analysis/risk factor)

(cid:1) identification des risques potentiels et mise en place des plans d’action

pour les supprimer ou réduire leurs effets

(cid:1) Exigence (requirement)

(cid:1) Caractéristique que doit posséder la solution pour répondre aux besoins de ses utilisateurs ou se conformer à une contrainte (norme, standard, spécification ou autre)

Approche Classique

Définitions (5/7)

28

(cid:1) Ressources (resource) :

(cid:1) humaines = personnes travaillant sur un projet à un

instant t, équipe projet

(cid:1) matérielles = outils , matériaux, financements,

nécessaires à la réalisation du projet

(cid:1) Effort : équivalent à un coût (effort)

(cid:1) temps passé par l’ensemble des ressources humaines sur

le projet

(cid:1) = somme des temps passés par chaque personne.

Exprimé en homme.mois en homme.année

7

Approche Classique

Définitions (6/7)

29

(cid:1) Tâche / Activité (task/activity):

(cid:1) sous-partie d’un projet organisées selon une relation d’ordre partiel

(parallélisme, dépendance)

(cid:1) responsabilité d’un membre de l’équipe projet (ou chef de projet)

(cid:1) Contraintes (constraints) :

(cid:1) Propriété qui doit absolument être respectée : pour des raisons de

sécurité (pas 2 avions en même temps au même endroit), à cause de la loi, parce qu’on ne peut pas faire autrement (on ne peut pas être à deux endroit à la fois en même temps)

(cid:1) Livrable (deliverable) :

(cid:1) Produit ou service remis formellement par un fournisseur à un client. (cid:1) Doit respecter un protocole, défini par contrat entre le fournisseur et le client : forme, contenu, échéancier de réalisation, normes à respecter, procédures de livraison, d’approbation etc.

Approche Classique

Définitions (7/7)

30

(cid:1) Recette/qualification/homologation (validation) :

(cid:1) Ensemble des actions de contrôle nécessaires à la reconnaissance

formelle de la conformité d’un livrable à des exigences contractuelles

(cid:1) Découpage du projet dans le temps: Jalon – phase

(milestone) (cid:1) Phase = période de réalisation (cid:1) Jalon : Point de passage où l’on confronte formellement

l’ensemble des résultats obtenus pendant la phase aux résultats attendus

(cid:1) Lot, sous projet, chantier (workpackage) :

(cid:1) Décomposition d’un projet pour le maîtriser plus facilement. (cid:1) Se termine par la remise d’un livrable.

Approche Classique

Activités de Gestion

Approche Classique

Définitions des types de Gestion

31

32

Planifier

Organiser

Suivre

Maitriser

(cid:1) Gestion des délais: consiste à planifier l’ensemble des activités du projet dans le temps et à les piloter de façon à respecter au mieux les engagements initiaux.

Estimations

(cid:1) Gestion des ressources: consiste à piloter efficacement les ressources humaines et matérielles afin de garantir la réussite du projet.

(cid:1) Gestion des productions (livrables): l'objectif d'un projet doit à son terme être concrétisée par une ou plusieurs fournitures (livraisons). Il faut s'assurer que ce qui est produit se rapproche du but final.

31

8

Approche Classique

Approche Classique

Définitions des types de Gestion

Les méthodes d’estimation (/)

33

(cid:1) Gestion des risques: identifier les risques potentiels et

mettre en place des plans d’action pour les supprimer ou réduire leurs effets.

(cid:1) Gestion des exigences: consiste à gérer les exigences

hiérarchisées d'un projet, à détecter les incohérences entre elles et à assurer leur traçabilité.

(cid:1) Gestion de configuration: consiste à gérer la description technique d'un système (produit) et de ses divers composants, ainsi qu'à gérer l'ensemble des modifications apportées au cours de l'évolution du système.

34

(cid:1) Pourquoi estimer ?

o Pour cerner la faisabilité du projet, le réalisme du délai

imposé

o Pour déterminer l’effectif à mobiliser o Pour négocier avec le client (maître d’ouvrage) o Pour planifier et éviter les dérives en temps et en coûts o Pour permettre la capitalisation des expériences o Pour disposer d’un temps convenu devant soi, pouvoir

s’organiser

o Pour ne pas travailler dans l’urgence

Approche Classique

Approche Classique

Les méthodes d’estimation (/)

Les méthodes d’estimation (/)

35

(cid:1) Quand faut-il estimer ?

36

(cid:1) Qu’est-ce que l’on estime ?

o En début de projet pour une première évaluation “grossière” o Avant chaque étape importante o Avant tout engagement :

avant de répondre “oui” à qui vous demande un travail pour demain !

o Une charge de travail exprimée en

•

jours-homme • mois-homme

•

années-homme

une personne durant 1 jour une personne durant 1 mois de 20 jours une personne durant 1 année de 10 mois

o Un délai, fonction de la charge de travail et de l’effectif mobilisé, exprimé en jours, semaines de 5 jours, mois de 20 jours, années (rare)

o Un coût en unités monétaires o Un niveau de qualité : nombre d’anomalies à corriger selon le

temps

9

Approche Classique

Approche Classique

Les méthodes d’estimation (/)

Les méthodes d’estimation (/)

37

38

(cid:1) Définition charge : représente une quantité de

travail nécessaire, indépendamment du nombre de personnes.

(cid:2) Elle permet d ’obtenir un coût prévisionnel. (cid:2) Elle s ’exprime en mois/homme. (cid:2) Elle aide à définir la taille d ’un projet. (cid:1) Définition délai : est le temps consommé par le

projet.

(cid:2) Elle dépend du nombre de personnes, mais l ’évaluation

n ’est pas isotrope

(cid:2) 100 personnes pendant un mois ne sont pas équivalentes à 1

personne pendant 100 mois

(cid:1) Ordre de grandeur: selon les normes ISO:

(cid:1) Charge < 6 M/h (cid:1) 6 M/h ≤ charge ≤ 12 M/h (cid:1) 12 M/h ≤ charge ≤ 30 M/h ⇒ projet moyen (cid:1) 30 M/h ≤ charge ≤ 100 M/h (cid:1) 100 M/h ≤ charge

⇒ grand projet ⇒ très grand

⇒ très petit projet ⇒ petit projet

projet

Approche Classique

Approche Classique

Les méthodes d’estimation (/)

Les méthodes d’estimation (/)

39

40

La non méthode

(cid:1) Exemple: répondre à une offre avec un prix bas pour être sur de l'avoir, mais sans être sûr d'y gagner quelque chose en définitive (au point de vue financier).

Méthode Delphi (Elaborée en 1948 par la Rand Corporation)

(cid:1) Principe: Repose sur un raffinement successif de jugements portés

par plusieurs experts jusqu'à obtention d ’une convergence

(cid:3) Chaque expert propose une estimation basée sur son expérience. (cid:3) On publie le résultat (anonyme). (cid:3) Les experts sont invités à modifier ou à maintenir leurs estimations. (cid:3) On publie les résultats nominaux. (cid:3) Les experts refont la troisième étape. (cid:3) On analyse les disparités, on calcule la moyenne.

10

Approche Classique

Approche Classique

41

43

Les méthodes d’estimation (/)

Méthode de répartition proportionnelle

(cid:1) Principe: Elle s'appuie sur le découpage du projet en

différentes phases. On commence par faire l'estimation de la charge globale. Ensuite, on détermine la charge pour chaque phase du cycle de vie

Les méthodes d’estimation (/)

42

Méthode de répartition proportionnelle

(cid:1) Exemple :

Les méthodes d’estimation (/)

Méthode des Points Fonctionnels (Elaborée en 1979 par la A. Albrecht : IBM)

(cid:1) Principe: calculer à partir de tables établies pour

l’entreprise, donnant selon le nombre de points de fonction ajusté une charge en j/h ou m/h

(cid:1) Points de fonction: unité internationale pour évaluer la

taille d’une application informatique en terme de fonctionnalités opérationnelles

Approche Classique

Les méthodes d’estimation (/)

44

Méthode des Points Fonctionnels

(cid:1) Pour un projet donné on calcule son poids en

« points de fonction ».

(cid:1) Méthode:

(cid:1) Comptage des points au début du projet (cid:1) Evaluation : calcul de la taille, ajustement de la taille,

transformation en charge.

11

Approche Classique

Approche Classique

Les méthodes d’estimation (/)

Les méthodes d’estimation (/)

45

46

Méthode des Points Fonctionnels

Méthode des Points Fonctionnels

(cid:1) Exemple :

o Composants fonctionnels :

(cid:3) Groupe logique de données internes (GDI) (cid:3) Groupe logique de données externes (GDE) (cid:3) Entrée de traitement (ENT) (cid:3) Sortie de traitement (SORT)

(cid:1) Exemple :

o Complexité d ’un composant :

Faible • • Moyenne Elevée

•

o Nombre de points de fonction du composant :

•

Tableau de correspondance entre la complexité et le type du composant = > poids

Approche Classique

Approche Classique

Les méthodes d’estimation (/)

Les méthodes d’estimation (/)

47

48

Méthode des Points Fonctionnels

Méthode des Points Fonctionnels

(cid:1) Exemple :

o Le PFB est ensuite ajusté par une appréciation des

spécificités du projet.

• 14 points sont identifiés, auxquels est attribuée une note de 0

à 5 en fonction du degré d ’influence (réutilisabilité, portabilité, …)

o Le PFA ou nombre ajusté de points

•

PFA = (0,65 * (SOMME (Dii, i = 1 à 14)/100) * PFB

12

Approche Classique

Approche Classique

Les méthodes d’estimation (/)

Les méthodes d’estimation (/)

49

50

Méthode COCOMO (Proposée par Barry Boehm en 1981 : Construct Cost Model)

(cid:1) En fonction des hypothèses:

(cid:1) Il est facile à un informaticien d'estimé le nombre de

lignes source.

(cid:1) La complexité d'écriture d'un programme est la même

quelque soit le langage de programmation.

(cid:1) Il propose une méthode basée sur la corrélation

entre la taille d'un projet et sa charge

Méthode COCOMO

(cid:1) L’unité : l’instruction source (cid:1) Le modèle permet d’obtenir la charge de

réalisation en m/H et le délai normal recommandé

Approche Classique

Approche Classique

Les méthodes d’estimation (/)

Les méthodes d’estimation (/)

51

52

Méthode COCOMO

(cid:1) Formules de calcul :

(cid:1) Charge en mois/Homme = a (Kisl)b

(cid:1) Délai = c (Charge)d

(cid:1) Taille moyenne d'équipe = Charge / Délai

(cid:1) Kisl = kilo instruction source testée

(cid:1) Les paramètres a, b, c et d dépendent de la catégorie du projet.

Méthode COCOMO

(cid:1) Classification:

(cid:3) Projet simple:

< 50 000 lignes

(cid:3) Projet moyen:

50 000 ≤ lignes ≤ 300 000

(cid:3) Projet complexe:

> 300 000 lignes

13

Approche Classique

Approche Classique

53

55

Les méthodes d’estimation (/)

Méthode COCOMO

Les méthodes d’estimation (/)

54

Méthode COCOMO

Différentes méthodes d'estimation de charge EXERCICES

Exercice 1: Estimer la taille moyenne de l'équipe qu’i l faudrait prévoir pour développer un logiciel

estimé à environ 40 000 instructions sources.

Nous appliquons la méthode COCOMO et nous nous apercevons que c'est un projet simple. Nous

avons donc pour le calcul de la charge et du délai, les coefficients suivant:

a = 3.2 et b = 1.05 c = 2.5 et d = 0.38

Donc selon la formule de la charge:

charge = 3.2 (40)1.05 » 154 M/h délai = 2.5 (154)0.38 » 17 Mois

Ce qui nous donne: Taille équipe = charge / délai = 154/17 = 9 personnes.

Exercice 2: Sachant que la phase d'observation représente environ un tiers de la charge de l'étude

préalable, calculer la charge du projet en M/h et sa répartition dans le cycle de développement. Nous supposons que la charge de la phase d'observation a été estimé à 7,5 J/h.

Charge étude préalable = 3 x phase observation » 22 J/H Charge totale = 10 x charge étude préalable » 22x10 » 220 J/h

» 11 M/h

(cid:1) Exemple :

(cid:1)

Soit un projet visant à développer un logiciel de 40 000 instructions source

(cid:1) C ’est un petit projet par la taille

du logiciel.

(cid:1) Charge = 3,2 (40)1,05 = 154

mois/homme

(cid:1) Durée normale = 2,5 (154)0,38

= 17 mois

(cid:1) Ce qui donne une taille moyenne de l ’équipe = 154 / 17 = 9 personnes.

Approche Classique

Une des particularités de la gestion de projet

56

Projet ≠ relation " vendeur / acheteur " classique 1. un client achète un produit déjà réalisé afin de

2.

satisfaire un besoin le projet vise à produire une création originale répondant à un besoin spécifique qu'il convient d'exprimer de manière rigoureuse. Cette expression des besoins est d'autant plus difficile que le projet n'a généralement pas d'antériorité au sein de l'entreprise étant donné son caractère novateur.

14

Approche Classique

De la théorie à la pratique…

57

(cid:1) La gestion de projets est souvent réalisée dans l’à

peu prés : (cid:1) équipes inadaptées, (cid:1) chefs de projet peu impliqués, (cid:1) périmètre de projets élastiques, (cid:1) plannings fantaisistes, (cid:1) coûts mal maîtrisés.

La partie de l'image av ec l'ID de relation rId1 n'a pas été trouv é dans le fichier.

Approche Classique

58

Les étapes d’un projet

Approche Classique

Approche Classique

Les étapes du projet et leurs livrables

59

(cid:1) Chaque étape fait l'objet d'un livrable et d'une validation à partir d'un document spécifique. =>Cela permet de maîtriser la conformité des livrables à la définition des besoins ainsi que de s'assurer de l'adéquation aux objectifs de coûts et de délai. => A chaque étape, il peut être décidé d'arrêter le projet si la maîtrise d'ouvrage estime que les objectifs ne pourront pas être tenus.

60

Les étapes du projet (cid:1) On appelle " cycle de vie du projet " l'enchaînement dans le temps des étapes et des validations entre l'émergence du besoin et la livraison du produit.

15

La partie de l'image av ec l'ID de relation rId2 n'a pas été trouv é dans le fichier.

61

Approche Classique

62

L’avant projet : la phase préparatoire (cid:1) définir précisément ce que sera le projet afin d'aboutir à la mise au point de documents contractuels (faisant lieu d'un contrat) permettant d'engager la maîtrise d'œuvre et la maîtrise d'ouvrage dans le lancement du projet

(cid:2) L'étude d'opportunité But : étudier la demande des utilisateurs par rapport aux objectifs généraux de l'organisation et décider si le concept est viable.

Approche Classique

L’avant projet : la phase préparatoire (cid:1) L'étude d'opportunité

63

(cid:1) rédaction d'un document nommé " note de cadrage

« (= le livrable), validée par le Comité de Pilotage du projet (et éventuellement les instances décisionnelles selon l'enjeu du projet). La note de cadrage officialise l'intention de projet.

(cid:1) Lorsque l'idée du projet est formalisée, le Comité de Pilotage doit officialiser la mission du responsable de projet et en définir les clauses. La lettre de mission (éventuellement note de mission) est le document qui officialise la mission du responsable de projet.

Approche Classique

L’avant projet : la phase préparatoire

(cid:2) L'étude de faisabilité

64

(cid:2) vise à analyser la faisabilité économique, organisationnelle et technique de projet.

(cid:2) Analyse des besoins : à partir de l'analyse sommaire des besoins il convient de

faire une estimation grossière du coût d'investissement et de fonctionnement du

projet (en terme de moyens humains et matériels), des délais envisagés et des

éventuels retours sur investissement.

(cid:2) L'étude de scénarii : l'étude de faisabilité conduit à envisager plusieurs scénarii

pour évaluer les risques pesant sur le projet et s'accompagne d'un bilan

prévisionnel présentant le coût et les avantages du scénario.

Cette étape fait l'objet d'un livrable, le dossier de faisabilité, remis au Comité de Pilotage afin que chaque scénario soit étudié.

16

Approche Classique

L’avant projet : la phase préparatoire

Approche Classique

L’avant projet : la phase préparatoire

65

(cid:1) L'étude détaillée

66

(cid:1) L'étude technique

(cid:1) Étude plus approfondie des besoins (" conception générale « ) pour que la maîtrise d'ouvrage et la maîtrise d'œuvre puissent s'entendre sur un document contractuel. (cid:1) Les besoins sont exprimés uniquement de manière fonctionnelle et non en terme de solutions. L'analyse fonctionnelle des besoins permet ainsi de dégager les fonctionnalités nécessaires de l'ouvrage.

(cid:1) L'analyse fonctionnelle aboutit à la mise au point d'un

document définissant fonctionnellement le besoin (indépendamment de toute solution technique) : cahier des charges fonctionnel / dossier de conception.

(cid:1) Le Cahier des charges permet à la maîtrise d'ouvrage

d'exprimer son besoin de manière fonctionnelle, ainsi que de clarifier les contraintes imposées à la maîtrise d'œuvre.

Approche Classique

Phase de réalisation

67

(cid:2) La préparation

(cid:2) découper le projet en tâches afin de planifier

l'exécution de ces tâches et de définir les ressources à mobiliser. Les outils et méthodes suivantes sont généralement utilisées : (cid:2) L'organigramme des tâches, parfois appelé organigramme technique de projet (OTP), permettant de découper les projets en tâches élémentaires (itemisation)

(cid:2) La méthode Pert (cid:2) Le tableau GANTT

(cid:2) Il revient au maître d'oeuvre de mettre en place des

procédures

(cid:1) L'étude technique est la phase d'adaptation de la conception

à l'architecture technique retenue, tout en décrivant et documentant le fonctionnement de chaque unité du logiciel.

(cid:1) Le livrable de l'étude technique est le Cahier des Clauses Techniques Particulières (CCTP) ou cahier des charges détaillé. L'étude détaillée peut éventuellement s'accompagner de la création d'une maquette, ou prototype, permettant aux représentants des utilisateurs de vérifier que la solution retenue répond bien à leurs attentes.

Approche Classique

Phase de réalisation

68

(cid:1) La réalisation

(cid:1) étape de développement de l'ouvrage sous la

responsabilité du maître d'œuvre, et sous contrôle du maître d'ouvrage. L'accent doit être mis sur la communication afin de pouvoir prendre les décisions au plus vite en cas de problème.

(cid:1) Documentation

(cid:1) Elle accompagne nécessairement l'ouvrage lors de la

livraison. La documentation est souvent incomplète ou non à jour et pourtant il s'agit d'une des facettes essentielles de l'ouvrage car elle constitue le référentiel de base concernant l'ouvrage après réalisation.

(cid:1) Validation

(cid:1) Lorsque l'ouvrage est réalisé, il convient que le maître

d'œuvre s'assure qu'il répond au cahier des charges. On parle de tests unitaires pour désigner la validation par le maître d'œuvre de la conformité du produit à chacune des clauses du cahier des charges.

17

Approche Classique

Phase de mise en œuvre

69

(cid:2) Recette

(cid:2) " recette " (ou essais de réception) = vérification de la conformité de l'ouvrage à la demande formulée dans le dossier validé de conception générale.

(cid:2) processus rigoureux et méthodologique effectué dès la

réception de la commande.

(cid:2) est parfois dite provisoire pendant une période de temps

appelée délai de garantie.

(cid:2) Cette étape se conclue lors de l'expiration du délai de

garantie par la rédaction d'un dossier de recette (procès- verbal de réception définitive) cosigné par le maître d'œuvre et le maître d'ouvrage contenant les remarques du maître d'ouvrage et éventuellement le refus de l'ouvrage s'il n'est pas conforme au cahier des charges.

Approche Classique

Phase de mise en œuvre

71

(cid:1)Généralisation

(cid:3)déploiement en masse de l'ouvrage auprès des

utilisateurs finaux.

(cid:3)Un déploiement réussi sur les sites pilotes ne signifie

pas systématiquement que le déploiement généralisé va réussir. En effet, lors de l'expérimentation, les utilisateurs ont une motivation que les utilisateurs finaux n'ont pas. De plus chaque dysfonctionnement de l'ouvrage est mis sur le compte de l'expérimentation. La généralisation implique généralement des changements dans la façon de travailler des utilisateurs, ce qui freine l'adoption du produit par les utilisateurs.

Approche Classique

Phase de mise en œuvre

70

(cid:1) Qualification

(cid:1) La qualification consiste à vérifier la conformité des capacités de l'ouvrage aux spécifications techniques du maître d'ouvrage. (cid:1) Mise en production

(cid:3) Sites pilotes : la mise en place de sites pilotes permet de tester l'ouvrage dans sa dimension technique, comme dans celle de l'organisation et de l'adhésion des utilisateurs. L'expérience des sites pilotes permet de préparer le déploiement, de mieux en apprécier la charge, et d'en identifier les difficultés a priori.

Approche Classique

Phase de mise en œuvre (cid:2) Généralisation

72

(cid:2) On désigne ainsi par " conduite du changement "

tous les éléments permettant de faire en sorte que les utilisateurs finaux utilisent réellement le produit, et donc changent leurs habitudes. Ce terme englobe notamment la formation des utilisateurs à l'utilisation du produit ainsi que l'accompagnement des utilisateurs (hot line).

(cid:2) lorsque le projet vise un nombre d'utilisateurs finaux très important, il n'est souvent pas envisageable de passer directement d'une expérimentation à une généralisation. Selon l'ouvrage il peut être nécessaire de faire des tests de montée en charge (on trouve parfois le terme de montée en cadence), c'est-à-dire simuler un nombre d'utilisateurs de plus en plus grand afin d'estimer si le produit est potentiellement capable de supporter la charge totale (utilisation simultanée par le nombre

18

Approche Classique

Phase de mise en œuvre

73

(cid:1) Capitalisation

(cid:1) archiver, l'expérience métier (savoir-faire) qui découle du projet afin d'améliorer l'efficacité de la conduite pour les projets futurs.

(cid:1) Une réunion de bilan sur le projet (debriefing) est bénéfique

pour les acteurs du projet car elle permet de passer en revue toutes les déviations du projet et les mesures correctives entreprises.

(cid:1) Maintenance

(cid:1) ensemble des opérations de modification d'un logiciel

opérationnel laissant intactes ses fonctionnalités de base.

(cid:1) permet de maintenir un système en fonctionnement en rectifiant les anomalies de l'ouvrage et en prenant en compte les demandes d'évolution des utilisateurs.

La partie de l'image av ec l'ID de relation rId1 n'a pas été trouv é dans le fichier.

Approche Classique

74

Découpage d’un projet informatique

Cas – Implémentation d’un système de gestion de portefeuille dans une banque privée

Source : Solvay Business School, Pascale Vande Velde,

Approche Classique

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

75

(cid: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

(cid:1) 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

(cid:1) Release 3 : enrichissement du flux d’ordres, roll out du package sur 200 utilisateurs répartis dans 20 agences

(cid:1) Planning

(cid:1) Release 1 : juin 2008 à août 2009 (cid:1) Release 2 : septembre 2009 à juillet 2010 (cid:1) Release 3 : juillet 2010 à fin 2010

Approche Classique

La structure d’un projet

76

(cid:1) Un projet sera, si nécessaire, divisé en sous projets

(cid:1) Chaque sous projet sera géré par un project manager (cid:1) Les project managers rapporteront à un program manager, en

charge de l’ensemble du projet

(cid:1) Le program manager rapportera l’état d’avancement du projet

à un comité de pilotage

(cid:1) Pour de gros projets, il existe un Program Management Office,

en charge du suivi financier et administratif du projet

(cid:1) La participation des métiers au projet

(cid:1) Le sponsor du projet est, en général, un directeur du métier

concerné

(cid:1) Via un co management d’un projet par l’IT et le métier concerné (cid:1) 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)

19

Approche Classique

Approche Classique

77

Mois

Comité IT

Sponsor

Mois

Comité de pilotage (*)

Hebdo & journalier

Program Manager

(cid:3) Coordination architecture

(cid:3) Support

fonctionnel et technique

Architecture

Hebdomadaire

PMO

Journalier

Journalier

Project Manager

Project Manager

Project Manager

•

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

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

|78

Program manager

Architecture

Implémentation Package

Change Management

Interfaces banque

Approche Classique

Le rôle des membres du comité de pilotage

79

(cid:1) Rôle

(cid:1) Gardien de la vision et des objectifs du projet (cid:1) Gère la communication sur le projet vis-à-vis de tiers (cid:1) Suit le planning et les délivrables, pas les processus

(cid:1) Responsabilités

(cid:1) Règle les problèmes organisationnels et de ressources (cid:1) Gère l’allocation des ressources et les dépendances entre projets

(cid:1) Est responsable de la communication au sein et en-dehors du projet (cid:1) Valide les délivrables (cid:1) Gère le périmètre et mitige les risques

(cid:1) Fréquence de réunion : 1x/mois

Approche Classique

Le rôle du program manager

80

(cid:1) Rôle

(cid:1) Gardien du planning du projet (cid:1) Assure la gestion du projet au jour le jour (cid:1) Gère le statut du projet (cid:1) Escale à temps et de manière appropriée les problèmes au comité de

pilotage (cid:1) Responsabilités

(cid:1) Coordonne les parties et s’assure de la réalisation du projet à temps (cid:1) Gère, planifie les ressources (cid:1) Gère les aspects financiers du projet (cid:1) Adhère aux best practices, méthodologies et outils de développement (cid:1) Gère le périmètre et les risques

20

Approche Classique

Approche Classique

Exemple Gouvernance du projet (Approche Classique en V)

81

Définir les objectifs

Comité de pilotage

Valider les objectifs

Program Mgmt

Project Management

Définir le périmètre du programme

Valider le périmètre du programme

Définir le périmètre du projet

Valider le périmètre du projet

Résoudre les problèmes

Gérer le périmètre en ligne avec attentes métiers

Résoudre/escaler les problèmes

Gérer le périmètre du programme

Résoudre/escaler les problèmes

Exécution du projet

Gérer le périmètre du projet

Les grandes phases d’un projet d’implémentation

82

(cid:1) 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

Tests d’acceptation

Déploiement

30-40%

20%

20%

20%

0-10%

Approche Classique

Approche Classique

La gestion des environnements

Change Infrastructure

PMO

Design

Build

Test

Roll-out

83

84

Conduite du changement

Program Management Office

(cid:1)

Gestion des ressources

• •

Suivi du budget Suivi du projet

Infrastructure

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

s k s a T

• 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

• Définir le contenu des formations • Définir les nouveaux processus, l’impact sur des

de test

• Effectuer des tests d’intégration • Effectuer les tests d’acce