Wiki Campus 3

fiche UE du CNAM

La gestion de projet est une activité ancienne mais une discipline récente. Quelques lois illustrent la difficulté de la conduite d'un projet.
Un projet informatique est un cas particulier de projet qui présente des difficultés liées à ses spécificités.

Si on ne sait pas ce qu'il faut au client, démarrer le projet serait voué à l'échec. Il faut donc une expression du besoin ou cahier des charges. Les attentes du client, exprimées en termes de fonctionnalités, peuvent être regroupées et représentées sous forme d'une hiérarchie des fonctions ou d'un diagramme de cas d'utilisation. La demande du client peut être complétée par la description de l'infrastructure existante, à utiliser pour la solution ou par la description de l'infrastructure préconisée. Il s'agit dans les deux cas d'une expression technique du besoin, représentée par un diagramme de déploiement.

Le besoin étant connu, il faut répondre à des questions telles que :
- combien de temps sera nécessaire pour y arriver ?
- combien cela va-t-il coûter ?

Afin d'y répondre, on part des fonctions pour arriver au calendrier en passant par quelques étapes clés :
- description de la solution envisagée appelée aussi produit ou ouvrage,
- description des travaux nécessaires pour y arriver,
- estimation des travaux (durée et effectif).

Le produit imaginé pour répondre au besoin peut être décrit sous forme d'une hiérarchie regroupant ses constituants en sous-ensembles, l'arbre-produit ou Product Breakdown Structure. Chaque constituant du produit est le fruit d'un travail. Les tâches pour obtenir le produit sont regroupées en sous-ensembles dans un arbre des travaux ou Work Breakdown Structure.

Cela ne suffit pas pour planifier le projet. Il faut en effet préciser si certains travaux doivent être terminés pour que d'autres puissent commencer. On peut à cet effet indiquer quelles sont les prédécesseurs des tâches. Un graphe permet de représenter ces dépendances ou contraintes d'enchaînement, le réseau des antécédents, que l'on doit à Henry Bartell Zachry.

Une estimation des durées et effectifs requis pour mener à bien les travaux complète la description du projet sous forme d'un tableau des tâches.
La planification de plus petite durée (au plus tôt) peut alors être faite en utilisant par exemple la méthode des antécédents. Le résultat peut être représenté sous forme d'une frise chronologique appelée diagramme de Gantt, du nom de l'américain Henry Laurence Gantt mais aussi inventée par le polonais Karol Adamiecki.
On peut aussi planifier au plus tard, en partant de la fin, c'est la rétro-programmation. Le calendrier obtenu diffère par certaines tâches pour lesquelles les dates de début au plus tôt et au plus tard sont différentes. Les autres tâches sont dites critiques puisqu'il n'y a aucune marge pour elles.

On peut aussi donner une estimation du coût en ressources humaines du projet sur la base du coût moyen unitaire de l'effort.

Le calendrier obtenu ne tient pas compte du temps calendaire (jours travaillés et jours chômés) ni des ressources réellement disponibles. L'ordonnancement consiste à prendre en compte ces deux aspects.

Pour savoir de combien de personnes on a besoin pour mener le projet à bien, on établit une courbe qui montre comment évolue l'effectif mobilisé sur le projet en fonction du temps : la courbe de charge. Le maximum de cette courbe donne l'effectif minimum de l'équipe projet. On peut alors constituer une équipe et la représenter sous forme d'une hiérarchie regroupant les ressources (matérielles et humaines) en sous-ensembles : l'arbre des ressources ou Resource Breakdown Structure.

On peut alors affecter les ressources aux tâches, ce qui revient pour les personnes à préciser qui fait quoi, en veillant à une bonne occupation des ressources, c'est-à-dire sans discontinuité ni sur-utilisation.
Il faut alors pour chaque tâche du projet désigner un responsable et préciser les autres rôles des acteurs du projet. On peut alors déterminer les contributions et les coûts des ressources, ce qui donne une estimation du coût du projet plus précise que celle obtenue par la planification.

La prise en compte du temps calendaire donne un calendrier plus long puisque les durées de date à date comprennent les jours travaillés mais aussi les jours chômés.

On peut mettre en oeuvre les notions vues ci-dessus dans cet exercice. Cet autre exercice s'appuie sur la compréhension des choses plus que sur l'application des techniques de calcul du calendrier.

La prise en compte des ressources réelles donne un calendrier différent parce qu'en mobilisant un plus petit nombre de personnes, il faut plus longtemps pour mener à bien le projet. Pour y arriver, on peut moduler l'effectif de certaines tâches, faire réaliser en séquence des tâches qui pourraient être menées en parallèle, ou combiner les deux techniques. Ces techniques sont utilisées dans le nivellement et le lissage des ressources. La solution retenue (parmi les différentes possibles) change aussi le(s) chemin(s) critique(s).

Une fois planifié puis ordonnancé, le projet peut commencer. Mais aussi bien cadré soit-il, les choses ne se déroulent pas comme prévu. Il faut donc suivre sa réalisation pour apprécier la situation réelle, la comparer aux prévisions et prendre les mesures adéquates pour corriger les écarts. Ce pilotage est effectué à différents niveaux de responsabilité.

Pour piloter le projet, on s'appuie sur des tableaux de bord qui en donnent une vision synthétique adaptée à la prise de décision. L'avancement est un des indicateurs utilisés.

Un tableau de suivi des tâches peut aussi être utilisé. Une restitution de l'état constaté peut être faite au moyen d'un diagramme de Gantt complété avec une ligne isochrone. Une autre peut utiliser un diagramme de Gantt complété avec une ligne de référence et actualisé pour représenter les impacts sur la suite du projet.
Ces différentes représentations posent la question de l'avancement global du projet, c'est-à-dire de la consolidation de l'avancement des différentes tâches.

Un autre suivi possible s'appuie sur les coûts. On parle de coûtenance et cela introduit de nouveaux indicateurs de performance (délai et coût). Cet exercice permet de mettre en pratique ce suivi et ses indicateurs. En voici le corrigé.

Les livrables permettent un suivi d'un point de vue externe à la MOE qui s'appuie sur la représentation de la dérive des jalons.

La prise en compte des écarts entre la situation réelle et la situation prévue amène à mettre en place des actions correctrices dont l'efficacité varie au cours de la durée du projet.

Le suivi et le pilotage se justifient parce que les choses ne se passent pas comme prévu, comme le dit bien la loi de Murphy. Les risques font partie de la vie d'un projet et il convient de s'y préparer. Cette gestion des risques passe par l'établissement d'un inventaire complété par une valorisation qui permet d'en déterminer la criticité afin de les hiérarchiser pour prévoir des parades aux risques les plus critiques si on n'a pas les ressources suffisantes pour les traiter tous.

La prise en compte des risques conduit à prévoir un délai plus long et des compléments de budget (réserve pour aléas et réserve pour imprévus).

La gestion des risques commence en amont du projet et se poursuit au cours du projet par un suivi et une mise à jour de la documentation des risques.

Un projet comporte plusieurs périodes au cours desquelles on mène des activités différentes en mobilisant des compétences différentes. On parle des phases d'un projet pour désigner ces périodes de travail. La notion de cycle de vie est relative à la succession des phases et la répétition du tout. On distingue alors les phases et les étapes, et les livrables du projet.

On distingue différents modèles de cycle de vie de projet (avec un plus ou moins grand nombre de phases) mais on peut s'accorder sur un découpage standard.

Une fois le projet terminé, la solution produite est exploitée. On parle de période d'exploitation ou d'opération. C'est alors le cycle de vie du produit avec ces quatre temps, caractérisés par une évolution du volume des ventes ou du chiffre d'affaire.

Un projet coûte (du temps, de l'effort, de l'argent) et il est rentable s'il présente un bon retour sur investissement, c'est-à-dire si la période d'exploitation permet de rembourser l'investissement ou mieux, permet de dégager des bénéfices. On procède pour déterminer la rentabilité à un calcul de retour sur investissement (ROI - Return On Investment).

L'exploitation du produit n'entraîne pas que du chiffre d'affaire. Il y a aussi des coûts d'exploitation (fixes et variables). Les coûts fixes ne dépendent pas du nombre d'utilisateurs (ou d'acheteurs) tandis que les coûts variables sont proportionnels au nombre d'utilisateurs. La prise en compte du coût du projet, des coûts d'exploitation et des revenus engendrés par l'utilisation du produit permet de déterminer à quel moment les revenus ont remboursé les coûts, c'est ce qu'on appelle le point mort. Au delà de ce point, on fait des bénéfices. Il faut donc que ce point ne soit pas trop lointain car si c'est le cas, il est possible que les bénéfices durent peu de temps avec le déclin du produit.

Ce calcul est généralement fait assez tôt dans le projet pour déterminer sa faisabilité financière et décider de la poursuite ou de l'abandon du projet.

En gestion de projet, on considère le triplet Coût-Délai-Qualité en focalisant la démarche sur le coût et le délai parce qu'ils sont mesurables alors que la qualité s'apprécie mais ne se mesure pas toujours (quoique !).

Pour obtenir la qualité voulue, il faut s'en donner les moyens, c'est-à-dire exiger que les membres de l'équipe fassent du bon travail et aussi le vérifier par des tests. Cela ne garantit pas qu'il n'y a pas de défaut dans le produit mais cela doit permettre de réduire le nombre des défauts.

Une partie de l'équipe doit être dédiée aux tests et peut y travailler dès le début du projet pour préparer la validation du produit. Elle s'appuie pour cela sur les exigences et les spécifications.

Une fois conçus, les tests à réaliser sont consignés dans des fiches de test et lorsqu'un test est effectué, on enregistre le résultat du test dans une fiche de résultat. Ces documents peuvent être dématérialisés si l'on utilise des logiciels dédiés tels que les référentiels de tests. Dans tous les cas, ces pratiques permettent, par une analyse des résultats, de déceler des défauts pour les corriger et améliorer ainsi la qualité du produit ou d'établir que le niveau souhaité de qualité est atteint, ce qui permet l'arrêt des tests.

Le produit peut alors être livré au client qui procède, de son côté à un contrôle de qualité : la recette.

L'approche classique demande du temps pour cadrer le projet et aussi pour actualiser le planning à chaque suivi. Elle utilise de nombreux outils (PERT, diagramme de Gantt, CBTP, CBTE, CRTE, IPD et IPC, graphe de tendance coûts-délais, diagramme temps-temps, tableau de bord…) et tout cela contribue à une certaine lourdeur, d'où l'idée d'utiliser des approches plus "légères".

Plutôt que d'établir un plan détaillé de réalisation des travaux, l'approche agile propose de se fixer un premier objectif à court terme, se lancer sans tarder et une fois cet objectif atteint, d'adapter la suite en fonction de la situation et de l'expérience acquise jusque là.

Le manifeste agile pose les bases de ces approches : 4 valeurs et 12 principes.

Le cahier des charges du projet prend la forme d'un carnet de commande (product backlog) constitué d'histoires d'utilisateurs (user stories). Chacune d'elle est caractérisée par sa valeur pour le client (chiffre d'affaires prévisible ou part du budget du projet).

On n'estime pas la charge de travail (temps et effectif) requise pour mener à bien les travaux mais la difficulté pour satisfaire les histoires d'utilisateurs. Cette difficulté est mesurée en points qui sont propres à l'équipe, propres au projet. L'échelle de difficulté est donc relative (pas absolue) mais elle est stable tout au long du projet.

Ce n'est pas un chef de projet qui procède à l'estimation mais l'équipe toute entière (elle est constituée avant le projet) au cours d'une réunion d'estimation (planning poker).

A l'issue de cette estimation, les éléments du carnet de commande sont caractérisés par leur valeur pour le client et leur difficulté pour l'équipe. La planification consiste à distribuer sur les périodes successives de travail, les éléments du carnet de commande qui seront satisfaits : on parle de planification des livraisons et cela conduit à un plan de livraison (release plan) plutôt qu'un calendrier des travaux.

Parce que l'effectif de l'équipe ne change pas au cours du temps et que les périodes de travail successives ont la même durée, la courbe du TAF (travail à faire) montre une diminution linéaire selon le plan de livraison.

Parce qu'elle apporte en premier des réponses aux attentes qui ont le plus de valeur pour le client, l'approche agile livre à la fin de chaque période de travail un produit partiel mais dont la valeur est importante tôt dans la durée du projet. On peut établir une courbe de la valeur du produit livré pour rendre compte de la prévision de livraison. Cette courbe peut être comparée à celle de la valeur acquise en approche classique de gestion de projet.

Cette planification prend peu de temps et s'il faut la réviser après une période de travail (sur la base de l'expérience passée), cela ne pose pas de problème. Il est donc possible de prendre en compte de nouvelles demandes du client à la fin d'une période de travail.

Les membres de l'équipe choisissent les tâches qu'ils vont réaliser car il n'y a pas de chef de projet. Il faut cependant éviter que 2 membres de l'équipe choisissent la même tâche et y travaillent sans savoir qu'un autre fait le même travail. Il faut pour cela savoir ce qui est en cours de réalisation.
Il faut aussi savoir ce qui reste à faire pour ne pas faire quelque chose de déjà fait.
L'outil de coordination utilisé est un tableau des tâches ou tableau d'itération. C'est aussi un outil de suivi puisqu'il permet d'apprécier le travail en cours (Work In Progress) et ce qui est terminé.

Le suivi peut aussi s'appuyer sur la courbe réelle du TAF, établie à la fin de chaque période afin d'apprécier l'avancement réel du projet par rapport aux prévisions. On peut de la même façon établir la courbe réelle de la valeur livrée du produit pour rendre compte de la réalité des livraisons effectuées.

Les méthodes Agiles sont nombreuses et on peut citer, de la plus ancienne à la plus récente :
- Scrum
- Rapid Application Development
- Crystal Clear - Feature Driven Development
- eXtreme Programming
- Lean Software development
- DevOps
- Lean startup
- Kanban

Tout projet est un processus de changement qui fait passer d'une situation initiale à une situation modifiée par l'introduction d'une solution qui répond en tout ou partie au cahier des charges.
La nouvelle situation peut conduire les utilisateurs à procéder différemment par rapport à la situation initiale.
Les processus concernés peuvent être modélisés (avant et après le projet) pour illustrer les manières de faire, apprécier les différences, mesurer les avantages et inconvénients… ou plus simplement pour décrire et communiquer la nouvelle manière de procéder.

Il existe différents modèles de processus. MERISE par exemple propose un modèle conceptuel et un modèle organisationnel des traitements. BPMN propose aussi une notation pour les processus métier. UML (dont on a vu le diagramme de cas d'utilisation pour l'expression fonctionnelle du besoin et le diagramme de déploiement pour l'expression technique du besoin) propose différents modèles de traitement et en particulier le diagramme d'activité.

Le changement est à la fois porteur d'espoir (le projet va répondre aux attentes) et de crainte (de nombreux aspects peuvent être contrariés ou remis en cause par l'exploitation d'une solution qui n'existait pas avant le projet). Il est donc nécessaire de conduire le changement, ce qui passe par différents éléments, une personne chargée de conduire le changement, le manager de transition et une vision partagée du projet.

Le corpus des connaissances en gestion de projet ou PMBOK (Project Management Body Of Knowledge) rassemble tout le savoir, les informations et les bonnes pratiques pour piloter tous types de projets dans les meilleures conditions en développant cinq groupes de processus décrits dans cette synthèse.

Le Project Management Institute propose des formations et différentes certifications dans le domaine de la gestion de projet.

Pour les projets informatiques, un ensemble d'ouvrages recensant les bonnes pratiques de gestion du système d'information est fourni par ITIL (Information Technology Infrastructure Library) qui met l'accent sur la notion de Système d'Information et service informatique au service des usagers.

hiérarchie des fonctions (Function Breakdown Structure)
diagramme de cas d'utilisation
diagramme de déploiement
arbre-produit (Product Breakdown Structure)
planification et ordonnancement
développement par itération et les conclusions à en tirer
réunion d'estimation
plan de livraison 1
plan de livraison 2
tableau d'itération
révision de plan de livraison
diagramme d'activité 1
diagramme d'activité 2
diagramme d'activité 3
diagramme d'activité 4

Afin de démontrer son aptitude à préparer un projet pour qu'il se déroule bien, une étude doit être menée et elle fait l'objet de la rédaction d'un document de projet et d'une soutenance orale. Les projets travaillés doivent présenter un caractère industriel, un caractère réaliste et de bonne envergure (exemples : refonte d'un helpdesk, constitution d'une base de connaissances, évolution d'un ERP, mise en place d'un système de Business Intelligence, …). La nature des sujets peut provenir de domaines divers.

Ce travail compte dans la notation de l'Unité d'Enseignement de la façon suivante :
1ère session :
- examen (1/4)
- exposé (1/4)
- document projet (1/2)
2ème session :
- examen (1/2)
- document projet (1/2)

Le document projet (qui n'est pas le rapport UAALOV - compte-rendu du travail effectué en entreprise pendant l'alternance) démontre qu'on sait cadrer un projet (à venir) en le préparant correctement et en prévoyant sa conduite. Il comportera entre autres les chapitres suivants :

• analyse de l'existant (avant projet) (contexte, situation de départ)
• description du projet (travail à faire pour améliorer ou corriger l'existant = présentation du besoin)
• objectifs (tous, pas seulement ceux qui restent à satisfaire si le projet est commencé - diagramme de cas d'utilisation)
• description du ou des processus concernés, voire évolution des processus (processus impacté·s et en quoi - représentation de processus par diagramme d'activité)
• contraintes
• risques (avec valorisation - probabilité-impact, établir la matrice des risques, parades pour les risques selon le niveau de criticité choisi, mise à jour de la gestion des risques et documentation des risques)
• qualité (fiches de test et de résultat)
• choix de solution (PBS)
• estimation des charges (en Hj si approche classique ou points de difficulté si approche agile)
• planning prévisionnel (diagramme PERT ou réseau des antécédents puis diagramme de GANTT, ou ligne de temps, ou plan de livraison…) en tenant compte :
  • des risques (tampons de sécurité pour aléas et imprévus)
  • de la qualité du produit (planification des tests, recette)
• analyse financière (estimation des coûts, retour sur investissement)
• architecture informatique (applicatifs, serveurs, équipements - diagramme de déploiement)

L'écrit surveillé comprend des exercices de gestion de projet classique (réseau des antécédents, courbe de charge, diagramme de Gantt…) et/ou agile (plan de livraison, tableau de suivi, courbe du TAF, courbe de la valeur du produit livré…).