Fonctionnalités de gestion des données > Gestion de projets > Plans classiques > Objets de plan classique > Sous-projets
  
Sous-projets
* 
Les sous-projets sont uniquement disponibles dans les projets classiques. Si vous convertissez un projet en projet de type plan de projet avancé (EPP, Enhanced Project Plan), les sous-projets sont convertis en activités récapitulatives.
Les sous-projets permettent de scinder un gros projet ou programme en éléments séparés pouvant être gérés et exécutés par des équipes distinctes.
Le traitement par Windchill des relations entre sous-projets fait l'objet d'un certain nombre de limitations. Il est essentiel de comprendre les relations des informations du plan dans un sous-projet, par rapport aux projets ou programmes parents, afin de déterminer la meilleure méthode permettant de profiter au mieux des avantages d'un sous-projet.
A partir d'une vue d'espace ou de contexte d'un projet ou d'un programme, tous les projets ou programmes sont égaux. En d'autres termes, il n'y a aucun partage, ni héritage, des équipes, dossiers, documents, articles, actions, conférences, ressources et droits d'accès entre le projet ou programme parent et les éventuels sous-projets qui lui sont associés.
La seule relation qui existe entre un projet ou programme et un sous-projet se fait au niveau du plan. Un noeud dans un plan parent peut identifier une relation de sous-projet avec le noeud de plan de niveau supérieur dans un autre projet ou programme.
Le statut, l'avancement, l'effort et le coût du plan sont calculés depuis le plan enfant vers l'objet de plan du sous-projet, dans le plan parent auquel le plan enfant est associé.
Les relations de priorité ne peuvent pas être établies de sorte que les modifications du plan parent se propagent jusqu'au plan connexe. Par exemple, un changement propagé de dates de début dans le plan parent ne peut avoir aucune influence sur la date de début du plan connexe. La propagation ne se fait que du plan connexe au plan parent. Par exemple, si la date de fin estimée du plan enfant est repoussée et que le plan parent contient une règle de priorité sur l'objet de plan du sous-projet, les activités du plan parent qui doivent suivre la fin du plan enfant ne peuvent pas démarrer tant que le plan enfant n'est pas terminé.
Le projet ou programme enfant doit exister avant de pouvoir être lié. Vous pouvez cependant définir un sous-projet dans le projet ou programme parent afin qu'il serve de repère jusqu'à ce que vous soyez prêt à associer le projet ou programme enfant.
Il n'est pas possible de définir des relations de dépendance à partir des activités parentes vers les activités du plan connexe.
* 
Si vous devez créer des relations de dépendance entre les éléments d'un plan parent et ceux d'un plan connexe, il est préférable de définir et de gérer l'ensemble du plan dans le parent. Dans ce cas, comme aucun plan n'est créé dans le projet ou programme enfant, ce dernier est utilisé comme un espace de collaboration ciblée avec une équipe, des dossiers, des actions et éventuellement des livrables uniques. Un responsable de projet ou de programme dans l'espace du projet enfant peut également être désigné dans l'espace du projet ou programme parent et se voir attribuer la responsabilité de définir, d'exécuter et de modifier une partie du plan dans le projet ou programme parent (représentant ce qui a pu être défini dans le projet ou programme enfant).
Pour gérer un plan complexe, vous pouvez attribuer la responsabilité de chacun des noeuds du plan parent principal au responsable de projet ou de programme d'un sous-projet. Celui-ci peut définir un lien hypertexte dans le sous-projet vers le noeud du plan dans le projet ou programme parent et simplement développer ce noeud, puis modifier les principaux objets de plan sous ce noeud.