reference:structure_projet_pluriannuel [Wiki Logeproj]

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Structurer un projet pluriannuel ======

Année budgétaire, année de réalisation, période de réalisation, arborescence : il n'est pas toujours aisé d'anticiper les conséquences qu'auront ces choix sur la gestion d'un projet. Cette page propose de lister les différentes manières de structurer un projet et d'évaluer les avantages et inconvénients de chaque possibilité.

<WRAP center round important 60%>
Dans Logeproj, certains libellés ne sont pas unifiés. Ainsi, l'année budgétaire associée à un projet est aussi parfois libellée année de programmation, année de programme ou encore année comptable.
</WRAP>

Pour simplifier et rester lisible, on prendra le cas d'un projet s'étalant sur trois ans mais pour lequel un seul intervenant est prévu sur une seule action (130 heures).

===== 1. utilisation d'une seule année budgétaire, d'un seul sous-projet et d'une seule prévision =====

La manière la plus simple de monter le projet est de créer un sous projet dont l'année budgétaire est 2017 (le libellé peut être 2017 ou autre chose, cela n'a pas d'importance). On crée ensuite l'action et on prévoit du temps pour l'intervenant. La période de prévision correspond à la durée réelle de l'action. On obtient donc un projet structuré ainsi :

{{ :guides_pratiques:utilisation:structure_projet_pluriannuel:une_annee_de_programmation-une_prevision.png?nolink |}}

==== Conséquences ====

  * **Coûts :** dans ce cas, un seul coût est utilisé (prévisionnel et réalisé) : il n’y a pas de revalorisation en fin d’année. De plus, il est nécessaire d'être vigilant à [[focus_sur_la_periode_d_utilisation_d_un_cout|la période d'utilisation du coût]]. En effet, celle-ci doit obligatoirement comprendre la période de prévision de temps. le coût doit aussi être utilisable pour l'année budgétaire 2017 (cf. [[comprendre_la_gestion_des_couts_dans_logeproj_v4|Comprendre la gestion des coûts dans Logeproj]])
  * **Saisie des temps :** l’intervenant voit le temps prévu ( 130 heures) sur cette action de manière globale (pour les trois années). Il devra continuer à saisir du temps sur l’année de programmation 2017 en 2018 et en 2019. En effet, dans la grille de saisie des temps, les lignes de saisie sont regroupées par année budgétaire.
  * **Plan de charge :** pour obtenir un plan de charge, il est nécessaire d’utiliser les reports et de les anticiper.
  * **Gestion du projet et justification :** il n’est pas nécessaire (ni possible à moins de basculer vers la solution suivante) de détailler le prévisionnel chaque année, le temps est prévu globalement au montage du projet: le détail du nombre d’heures prévues par année n'est pas saisi.
  * **Fichier d’import :** un seul fichier d’import est nécessaire.

<WRAP center round tip 60%>
**Pourquoi créer un sous projet ?** En réalité, la création d'un sous-projet "2017" n'est pas obligatoire ; c'est l'année de programmation de l'action qui est importante. Il y a cependant plusieurs bonnes raisons de créer un sous projet intermédiaire :
  * Cela permet, si il est libellé "2017", de savoir d'un seul coup d'oeil que les actions sous-jacentes sont des actions programmées en 2017.
  * Si le projet est renouvelé plus tard, cela permet de ne pas mélanger les actions prévues lors de la première programmation de celles prévues lors de la suivante.
  * On verra plus bas qu'il est indispensable pour palier les limites de cette première solution en créant plusieurs sous-projets. Conserver cette convention permet donc une structuration des projets plus harmonisée, et par là une lecture facilitée. (d'ailleurs, l'utilisation du fichier d'import crée automatiquement ce premier niveau d'arborescence.
</WRAP>


===== 2. Utilisation d'une seule année budgétaire, d'un seul sous projet et de plusieurs prévisions =====

La méthode précédente ne permet pas de valoriser différemment les heures prévues et/ou réalisées en fonction de l'année. Il n'est pas possible de prévoir un coût différent pour les heures prévues en 2017, 2018 ou 2019. De la même manière, les heures réalisées en 2017, 2018 ou 2019 seront valorisées au même coût.
De plus, l'intervenant, lorsqu'il saisi son temps, ne sait pas quel volume d'heure est prévu en 2017, en 2018 et en 2019.

Pour palier ces inconvénients, il est possible de structurer l'arborescence de son projet de la même manière (un seul sous-projet dont l'année de programmation est 2017 et une seule action) mais créant plusieurs prévisions pour l'intervenant en utilisant des coûts différents.

{{ :guides_pratiques:utilisation:structure_projet_pluriannuel:une_annee_budgetaire-plusieurs_previsions.png?nolink |}}

==== Conséquences ====

  * **Coûts :** on utilise des coût différents selon la période de prévision, ce qui permet de valoriser les heures différemment. Cela implique de multiplier les coûts pour l'année de programmation 2017 (ici, trois coûts) ou de ne pas restreindre les coûts à l’année de programmation.
  * **Saisie des temps :** l’intervenant voit le temps prévu chaque année. Il ne peut saisir que sur la ligne correspondant à la bonne période mais il devra continuer à saisir du temps sur l’année de programmation 2017 en 2018 et en 2019.
  * **Plan de charge :** Pour obtenir le plan de charge, il est nécessaire d’utiliser les reports et de les anticiper.
  * **Gestion du projet et justification :** Il est possible d’ajuster le prévisionnel chaque année, le temps est prévu au montage du projet.
  * **Fichier d’import :** un seul fichier d’import est nécessaire.

===== 3. Utilisation de trois années budgétaires, de trois sous-projets et de plusieurs prévisions=====
Les deux méthodes précédentes présentent l'inconvénient d'exiger de l'intervenant de connaître à quelle année budgétaire est lié le projet. En effet, dans la fiche de saisie des temps, les actions sont regroupées par année budgétaire. Il est parfois contre-intuitif pour un intervenant de comprendre qu'il saisi en 2018 des temps sur une action dont l'année budgétaire est 2015.

De plus, pour la personne chargée de la gestion du projet dans Logeproj, anticiper des reports pour obtenir un plan de charge n'est pas très pratique, ni intuitif.

Enfin, cela oblige soit à ne pas limiter l'utilisation de ses coûts à l'année de programmation, ce qui augmente le risque d'erreur lors du choix d'un coût, soit à créer plusieurs coûts pour l'année de programmation 2017 (ici trois coûts associés à l'année de programmation 2017 : un pour les prévision 2017, un pour les prévisions 2018 et un pour les prévisions 2019).  

Pour palier cet inconvénient, il est possible de structurer l'arborescence du projet de la manière ci-dessous :

{{ :guides_pratiques:utilisation:structure_projet_pluriannuel:trois_annees_budgetaires-trois_previsions.png?nolink |}}

==== Conséquences ====

  * **Coûts :** on utilise un coût par année de prévision. Cela permet une gestion des coûts intuitive et de restreindre les coûts à l’année de programmation.
  * **Saisie des temps :** l’intervenant voit le temps prévu chaque année. Il saisi ses temps 2018 en 2018, ses temps 2019 en 2019 et ses temps 2020 en 2020.
  * **Plan de charge :** obtenir un plan de charge annuel est simple. Pas besoin des reports même si il reste possible de les anticiper.
  * **Gestion du projet et justification :** il est probablement indispensable d’ajuster le prévisionnel chaque année (re-répartition des heures sur les différentes années) en veillant à l’équilibre du budget.
  * **Fichier d’import :** trois fichiers d’import sont nécessaires.

===== 4. Regrouper les 3 années en intercalant un sous-projet =====

Si une programmation 2019-2021 doit être réalisée par la suite, la solution précédente présente encore un inconvénient : le sous-projet 2019 contiendrait des actions liées à 2017-2019 et à 2019-2020 sans qu'il soit possible des les distinguer. Il y a alors deux options : soit créer un nouveau projet pour la programmation 2019-2020 (il faut alors créer un nouveau code analytique et choisir un nouveau libellé pour le nouveau projet), soit procéder comme ci-dessous :

{{ :guides_pratiques:utilisation:structure_projet_pluriannuel:trois_annees-regroupement.png?nolink |}}

==== Conséquences ====

  * **Coûts :** on utilise un coût par année de prévision. Cela permet une gestion des coûts intuitive et de restreindre les coûts à l’année de programmation.
  * **Saisie des temps :** l’intervenant voit le temps prévu chaque année. Il saisit ses temps 2018 en 2018, ses temps 2019 en 2019 et ses temps 2020 en 2020.
  * **Plan de charge :** obtenir un plan de charge annuel est simple. Pas besoin des reports même si il reste possible de les utiliser.
  * **Gestion du projet et justification** : il est probablement indispensable d’ajuster le prévisionnel chaque année (re-répartition des heures sur les différentes années) en veillant à l’équilibre du budget.
  * **Fichier d’import :** trois fichiers d’import.

===== Conclusion =====

La dernière solution semble palier les inconvénients de toutes les autres. Pourquoi, alors, ne pas vous conseiller d'emblée de structurer vos projets de cette unique manière ? Simplement parce que la préparation de la programmation sous cette forme est plus longue : il faut éclater une action se déroulant sur 2017, 2018 et 2019 en trois actions dans Logeproj et cela démultiplie le nombre de prévisions. Dans le cas du projet d'exemple ci-dessus, cela ne semble pas insurmontable mais prenons le cas d'un projet sur cinq ans comportant 10 actions faisant chacune intervenir 10 intervenants : nous devrions alors créer 50 actions dans Logeproj et 500 prévisions de temps...

La manière de découper votre projet dépend donc fortement de vos contraintes (nombre et taille de vos projets, exigences de vos financeurs) et de ce que vous souhaitez obtenir (analyser plus ou moins finement votre activité, simplifier la saisie des temps aux intervenants du projet, disposer d'une gestion simple de vos coûts, obtenir plus ou moins facilement un plan de charge...). Il s'agit donc de choisir le meilleur compromis.