Gestion organisationnelle de projet et gestion financière de projet : deux mondes.

Lorsqu’on évoque la gestion de projet, on fait généralement référence à l’ensemble des outils de suivi que l’on utilise pour  s’assurer qu’on livre selon les trois critères universels :

  • Livraison dans les temps,
  • Selon les spécifications,
  • Selon le budget défini.

S’il est relativement simple de lister les spécifications requises et  de s’y conformer, et s’il  est aisé, (tout est relatif bien entendu) de planifier la date finale de livraison d’un projet, il est en revanche plus délicat d’intégrer les changements et les impondérables qui peuvent survenir lors de son exécution. En règle générale, les outils de gestion de projet permettent de bien gérer ces modifications en cours de route et d’en limiter les risques, tout au moins d’un point de vue organisationnel. Il n’en demeure pas moins vrai que ces changements ont un impact sur la composante financière du projet.

Dès lors, le concept de livrer « selon le budget défini » revêt un caractère souvent aléatoire.

L’importance du mode facturation est évidente :

Si l’on facture au réel alors le ciel est bleu et sans nuages. Quels que puissent être les changements intervenants dans la vie du projet, la facturation s’effectuera selon le nombre d’heures réellement engagées dans l’exécution des services, et si la question des dépenses a bien été négociée, celles-ci seront facturées au réel. En revanche des coûts imprévus peuvent se profiler après la livraison du projet.

Si l’on facture selon une base forfaitaire il faudra bien, tôt ou tard, se poser la question : que faisons-nous si notre facturation forfaitaire ne reflète pas la réalité du terrain ? Autrement dit;  si nous facturons forfaitairement  l’équivalent d’un nombre d’heures inférieur aux heures réellement travaillées ?  Allons-nous poster cette différence dans les pertes, ou bien amorcer une négociation avec le client ? Tout dépendra du bon vouloir client, du détail des pièces justificatives, et de notre talent de négociateur.

Quoiqu’il en soit, à ce stade nous nous situons encore dans le cadre de la livraison des services, mais qu’en est-il des  services rendus aux clients au-delà de la livraison du projet ?

Bien que ces derniers surviennent à postériori, s’ils n’ont pas été budgétés initialement ils vont affecter le niveau de profitabilité du projet.

Prenons un exemple de développement d’un logiciel industriel.

Mon projet se compose de trois étapes : analyse des besoins,  développement,  mise en service. Pour l’ensemble de ce projet j’ai prévu  respectivement 25, 100, et 50 heures; soit un total de 175 heures. Mon coût moyen horaire est 35 $ et mon tarif horaire moyen est 70 $. L’entente avec le client est basée sur un montant forfaitaire de  14 000,- $ (175 heures plus un coussin de sécurité de 25 heures, au taux de  70 $).

J’ai sous-estimé, lors de mon analyse,  les besoins en développement. De plus,  la version Béta  comportait des bogues que j’ai dû régler. Au total j’ai  passé 40 heures de plus que prévu dans mon budget initial (hors coussin de sécurité).  Conformément à mon entente avec le client j’ai facturé un montant forfaitaire de 200 heures et donc ai enregistré une perte de 15 heures, soit  525,- $(au coûtant). Le logiciel a été livré. Deux mois plus tard, le client m’informe qu’il y a des dysfonctionnements récurrents, et je dois travailler vingt heures à corriger la situation. Au  total, bien que le projet ait été livré j’ai enregistré une seconde perte équivalent à  700, $ (au coûtant). Résumons-nous :

Au-delà de la livraison du projet, des pertes financières peuvent intervenir. Il convient donc d’intégrer dans le budget prévisionnel un facteur de risques qui correspond dans le meilleur des cas au prix d’une année de contrat de service. Dans l’exemple cité il aurait fallu, outre le coussin de sécurité de 25 heures, prévoir un montant supplémentaire pour couvrir les risques post-livraison, par exemple 10 à 15 % du montant total. Abak, le logiciel de gestion de feuilles de temps, de facturation et de gestion de coût de projet comprend une composante de calcul budgétaire. Parlez-nous de vos projets, nous vous parlerons de vos budgets.

Le labyrinthe du trop détaillé

Quand il est question de gestion de projet on associe généralement la méthodologie de suivi à un morcellement en un nombre variable d’étapes et sous-étapes détaillées. La finalité de cette action, par le biais d’une arborescence, est  d’identifier  l’ensemble des composantes du projet que l’on va ensuite  distribuer sur un échéancier,  pour y associer des tâches,  assigner des ressources, et déterminer un ensemble de dates buttoirs. Cela part évidemment d’un bon sentiment, et en règle générale l’adage : « diviser pour mieux régner »  est tout à fait de circonstance. Le projet s’articule ainsi autour d’une série d’étapes successives. Pour chacune de ces phases on a défini la charge de travail, les responsabilités de chacun, et budgété le temps requis pour chacune des sous-étapes qui constituent la phase du projet. Il est vrai que pour définir adéquatement un budget il est préférable d’aller dans le détail des activités requises pour mener à bien l’exécution du projet, et pour chacune d’elles d’estimer le temps nécessaire à sa réalisation et les coûts annexes afférant.

Cependant dans cette belle mécanique de gestion peut se  glisser le grain de sable de la complexité et de la confusion. En effet, si l’architecture du projet est trop détaillée, les  intervenants courent le risque de s’y perdre lorsqu’ils vont devoir saisir leur temps,  et leurs dépenses.

Prenons un exemple : Mon projet se compose de douze phases. En moyenne chacune des phases est constituée de cinq sous-phases. Chaque sous-phase est articulée en un nombre moyen de quatre sous-étapes. Et enfin, chacune de ces sous-étapes se compose de trois à cinq types d’activités. Prenons l’activité ‘réunion’ pour exemple. Dans la phase (1) j’aurai donc le choix de saisir mon temps pour l’activité ‘réunion’  entre  cinq sous-phases et ensuite entre quatre sous-étapes.

Le risque d’erreur est donc extrêmement élevé, et tout particulièrement si le mode de saisie s’effectue de façon artisanale (via courriel, sur fiche, ou en utilisant Excel, par exemple)… Chaque erreur de saisie aura pour effet de débalancer le budget et pourra occasionner de violents maux de tête au contrôleur ou chargé de projet lors de la facturation si celle-ci s’effectue au réel et selon l’avancement du projet.

En matière de gestion de projet, il convient donc  de trouver le compromis idéal entre la détermination d’un budget réaliste et une arborescence de projet limitée aux phases et sous-phases principales.  Aller dans le détail des activités pour définir le budget est recommandé. En revanche, l’architecture du projet, pour des raisons évidentes de confort d’utilisation et de suivi devrait se limiter à l’essentiel.

Afin d’éviter ce piège, nous recommandons de valider la pertinence de chaque étape, et de bien définir les besoins au préalable lors de la création des matrices de projet. Abak logiciel de gestion de temps, facturation, et gestion de coût de projet vous guidera dans cette étape.

Contactez-nous, nos spécialistes vous conseilleront.