Avant toute chose, il est important de rappeler que le Project Network Diagram n’est pas un outil récent. Il a été développé dans les 40-50 ce qui lui vaut une confusion régulière avec le Diagramme de PERT.

Pour autant, peu de Chefs de projets connaissent son existence ou l’appliquent. Il est pourtant crucial pour démarrer sereinement un projet, comme nous l’avons vu dans l’article « Accepteriez-vous de monder une cuisine IKEA avec seulement la première page de la notice ? »

PERT, Diagramme de PERT, Project Network Diagram : quelle différence ?

Le PERT se désigne comme « une technique d’estimation qui applique une pondération des moyennes optimistes, pessimistes et réalistes lorsqu’il y a de l’incertitude dans l’estimation individuelle des durées de chaque tâches ». Rien à voir avec la notion de gamme que l’on voudrait faire porter au « Diagramme de PERT » (qui par ailleurs n’existe pas dans le PMBOK).

De son côté, le Project Network Diagram se définit comme « Une représentation schématique des liens logiques entre les activités de l’échéancier du projet. Toujours tracer de la gauche vers la droite pour refléter la chronologie des travaux du projet. ». On retrouve donc bien là l’idée d’un enchainement visuel de tâches.

Il est à noter que la plupart des méthodes d’amélioration continue autour des projets font référence à ce Network Diagram.

En effet :

  • Le Lean Engineering suggère de créer la Value Stream Map du projet qui représente une séquence identifiée entre différentes tâches.
  • Les méthodes AGILE suggèrent l’utilisation de Stories qui sont en fait un ensemble de tâches décrivant l’histoire du projet.
  • La méthode de la chaîne critique est quant à elle clairement explicite sur l’utilisation du Network Diagram : « Technique d’analyse du diagramme de réseau qui consiste à modifier l’échéancier du projet pour tenir compte des limites de ressources. Cette méthode combine les approches déterministes et probabilistes de l’analyse du diagramme de réseau. »

En définitive, on peut dire que les approches d’amélioration continue utilisent soit par défaut l’approche du network diagram soit elles ont créé des outils visant à s’approcher de cette idées.

Nous ne suggérons pas une méthode par rapport à une autre, du moment que celle que vous choisissez vous permet d’avoir la vue d’ensemble de votre projet de manière logique pour vous et vos équipes.

Le Project Network Diagram représente donc la gamme du projet.

Voyons maintenant comment il peut être construit *. C’est un processus qui est divisé en plusieurs grandes étapes :

1. La préparation 

Dans cette étape, il s’agit d’éclaircir les tenants et aboutissants du projet en définissant des éléments de langages sur ce qu’est un livrable , ce que « fait » veut dire au sein de l’équipe. Il s’agit de rappeler les diverses raisons et paramètres du projet (quoi, pourquoi, quand etc.). Enfin on identifie les grandes étapes majeures du projet ainsi que les données d’entrées et livrables de chaque étapes.

2. Construire le réseau de de projet

a. Nous allons tracer les liens logiques entre ces jalons et vérifier leur cohérence : « Si j’ai ces données d’entrée alors je peux accomplir cette tâche qui sera terminée quand j’aurai fourni ces livrables ». Cette phrase de contrôle permet de compléter les données d’entrées, livrables et autres éléments éclaircissant cette macro vue.

b. Le fait de générer ces livrables et données d’entrées permet de détailler davantage le macro jalon. Ainsi ce dernier peut être subdivisé tout en conservant la logique d’ajouter ces points d’entrées et sorties à chaque étape

c. On peut ensuite ajouter les ressources ainsi que les durées. Plusieurs astuces sont à prendre en compte :

  • Pour éviter tout débat, considérer une durée en fonction de la réponse à la question suivante : de combien de temps avez-vous besoin pour terminer cette tâche dans la durée estimée dans plus de 90% des cas ?
  • Lorsque le total de la durée du projet est fait, vous pouvez vérifier les tâches qui ont une durée inférieure entre 3% et supérieure à 10% de la durée totale du projet. Cela veut dire que les tâches sont trop ou pas assez détaillées.

Ces deux éléments de contrôle sont fondamentaux pour être certain d’atteindre le bon niveau de détail du planning que vous ferez par la suite. En effet, il est courant d’observer que les tâches sont souvent imprécises ou génériques et donc que la visibilité associée est très limitante.
Il convient de répéter ces 3 étapes (a ;b ; c) jusqu’à avoir :

  • Un ensemble de phrases racontant une histoire faisant sens ;
  • Un ensemble de tâche suffisamment fin pour être compréhensible de tous.

Nous avons un donc le schéma suivant qui inclut des ressources et des durées :

*A noter que cette méthode construction n’est pas unique. De plus, la plupart des approches d’amélioration de la fonction projet ont développé leurs propres approches. Celle que nous vous proposons est accessible gratuitement sur les articles de blogs de Kathy Austin >>

Le Project Network Diagram

Post navigation


4 thoughts on “Le Project Network Diagram

  1. Merci pour cet éclairage.
    Pour la détermination des liens logiques entre les tâches, il me semble important de bien faire le distingo entre ce qui est du registre de la contrainte, de la dépendance et ce qui est du registre de l’envie, de l’habitude.
    La contrainte ou la dépendance entre deux tâches doivent être matérialisées dans le réseau. Par contre l’envie ou l’habitude doivent en être bannis, afin d’éviter de créer des réseaux hyperstatiques n’offrant donc pas de flexibilité ou ne permettant pas l’organisation innovante du projet.

    1. Merci Benoît pour votre réponse.

      En effet, les deux notions sont importantes et méritent l’attention que vous y portez. Lorsqu’on parle de « liens logiques », nous évoquons l’histoire d’un projet avec ses données d’entrées, l’action et ses livrables. Il arrive très souvent qu’à la construction de ce Network Diagram, certaines tâches ou livrables ne soit reliés à rien !
      Comme vous l’avez perçu, certains de ces livrables appartiennent aux champs de l’habitude, de l’envie, etc. Lors de ce processus, nous remettons en cause l’existence de ces tâches ou livrables afin de concentrer l’équipe sur le projet.
      La situation que nous constatons dans le mode projet est que ces tâches émergent à l’intérieur d’un projet car les équipes n’ont plus le temps de faire cela à part. Donc elles tentent des actions d’amélioration continue en cours du projet ce qui les éloignent de l’objectif initial tout en favorisant un multitâche local et rallongeant la durée des projets. ».

      Une de nos actions est en général de faire émerger le projet dans lesquelles ces tâches annexes sont concernées. Puis d’intégrer l’ensemble de ces projets dans le Pipeline afin de favoriser la prise de conscience de ce que l’équipe a à réaliser, que cela soit en termes de projets clients ou projets internes.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Share via
Copy link
Powered by Social Snap