Le retour sur investissement ou ROI

Publié le 4 septembre 2014 par AdminArnaudBrossard
Le retour sur investissement (ROI) d'un projet

Le retour sur investissement (ROI) d’un projet

Aujourd’hui, peut-on vraiment encore parler de gestion de projet sans parler de la notion de retour sur investissement (Return Of Investment ou ROI en anglais) ?

La réponse est bien évidemment non.

En effet, pour toute société, un projet représente un investissement dont il faut connaître à la fois le coût mais aussi les revenus associés pour pouvoir correctement évaluer son impact réel sur l’entreprise et prendre les bonnes décisions.

C’est pour cela qu’il est indispensable de calculer, dès la phase initialisation du projet, un retour sur investissement (ROI) qui, dans la plupart des cas, se fera sur plusieurs années.

Mais déjà, quels retours peut-on attendre d’un projet ?

  • Un retour financier sous la forme d’économies directes sur les coûts de fonctionnement de la société.
  • Une amélioration de la satisfaction des clients de la société en vue de mieux les fidéliser. Cette amélioration peut passer par une amélioration des services et produits existants ou la mise en place de nouveaux services ou de nouvelles versions de produits.
  • Un retour financier sous la forme d’une augmentation de la part de marché (exemple : mise en place de nouveaux produits ou de nouveaux services).
  • Un retour immatériel sur l’image de marque de la société (exemple : amélioration de la visibilité de la société, montée en gamme de l’image de la société, etc.). Ce retour est généralement difficilement quantifiable même si son objectif est généralement d’augmenter les parts de marché de la société.
  • Un retour indirect lorsque le projet est lié à des contraintes extérieures obligatoires (exemple : obligation de passer à des échanges dématérialisés). Ce retour est indirect car s’il est indispensable pour répondre aux besoins et obligations des clients ne pas le faire ne permettrait, généralement, pas de rester sur le marché.

Une fois le ou les retours du projet identifiés, il devient alors possible de calculer la valeur totale de ce retour sous une forme financière. Dans la plupart des cas, ceci ne sera qu’une approximation car, sauf cas exceptionnel, il est difficile de prédire l’avenir avec beaucoup de certitudes. Mais, si ce calcul est effectué en prenant en compte le maximum de paramètres, celui-ci est généralement assez proche de la réalité.

Les principaux paramètres à prendre en compte sont :

  • Les économies attendues sur les ressources humaines, sur l’immobilier, sur le mobilier, sur les contrats externes, sur les fournitures, etc.
  • Les gains attendus sur l’augmentation du chiffre d’affaires, sur la marge opérationnelle sur les produits ou services, etc.

Au niveau des économies attendues, le point qui est généralement le plus délicat à aborder, pour un chef de projet, concerne les ressources humaines. De manière pratique, ce type de gains signifie qu’il y aura une réduction des coûts liés aux ressources humaines et donc, très probablement, des réaffectations de personnes, des non-remplacements de postes suite à des départs ou, dans certains cas, des licenciements. Cet aspect est souvent laissé de côté par un certain nombre de chefs de projet, pour différentes raisons, alors que sa prise en compte a souvent un impact important sur le calcul du retour sur investissement (ROI) du projet et donc sur les décisions qui pourront être prises à son sujet.

Pour les autres économies et gains attendus, en vérifiant que tous les impacts liés au projet sont bien pris en compte, il est généralement assez aisé de tous les définir et de les calculer.

Pour ce qui est de la détermination de la durée totale sur laquelle il faut calculer les gains et les économies pour être en mesure de calculer le retour sur investissement (ROI), il n’y a pas vraiment de règle absolue qui permette de la fixer. Ainsi, si le retour sur investissement attendu doit être rapide, il convient de limiter cette durée sur quelques mois ou quelques années. Par contre, si le retour sur investissement doit être global, il convient de calculer cette durée sur la durée de vie totale du projet, de sa date de mise en production à sa date de retrait de production.

Une fois la durée déterminée, il convient de répartir les différents gains et les différentes économies sur la globalité de cette durée. Ceci ne doit pas se faire de manière linéaire mais doit tenir compte des gains et économies attendus pour chaque période définie sur cette durée (une période étant la durée de temps minimale utilisée pour la répartition des gains et des économies). Une fois cette répartition effectuée, le chef de projet pourra faire apparaître, en face, la répartition des coûts associés au projet pendant cette même durée. Puis, il pourra réintégrer les coûts associés au développement et à la mise en oeuvre du projet (avant la date de mise en production).

Disposant alors de tous les coûts et de tous les gains et économies, l’utilisateur pourra alors calculer, au minimum, deux éléments importants pour la prise de décision :

  • Le solde financier du projet qui se calcule très simplement en prenant l’ensemble des gains et économies attendus auxquels on soustrait l’ensemble des coûts associés au projet
  • La date de rentabilité du projet qui est la date à partir de laquelle le projet pourra être considéré comme ayant des gains supérieurs aux coûts (attention, il est possible qu’un projet n’ait jamais de date de rentabilité si les objectifs de sa mise en oeuvre ne sont pas uniquement financiers).
  • La rentabilité brute du projet qui est un pourcentage qui se calcule en divisant le total des gains et économies du projet sur l’ensemble des coûts du projet.

Tous ces éléments forment la base du retour sur investissement (ROI) du projet.

Du point de vue de la gestion de projet, celui-ci ne sert pas uniquement comme un élément purement financier, mais comme un des critères de base du pilotage du projet aussi bien au niveau du chef de projet que des décideurs. C’est, en effet, ce retour sur investissement (ROI) qui permettra de décider s’il faut démarrer ou pas un projet. C’est lui qui pourra donner certaines inflexions au projet pour, par exemple, augmenter sa rentabilité à court terme. C’est encore lui qui pourra contraindre un projet à s’arrêter. Voilà pourquoi il est indispensable de faire évoluer, si nécessaire, les éléments de calcul de retour sur investissement dans le temps pour tenir compte de toutes les évolutions et événements qui peuvent survenir. Sans cela, il sera souvent difficile de juger objectivement de la pertinence d’un projet et donc de décider de sa mise en oeuvre, de sa continuation ou de son arrêt.

Publié dans ROI | Marqué avec , | Commentaires fermés sur Le retour sur investissement ou ROI

Coût – Délai – Qualité : La qualité

Publié le 3 septembre 2014 par AdminArnaudBrossard
La qualité dans un projet informatique

La qualité dans un projet informatique

La plupart des personnes qu’on rencontre dans le monde de l’informatique ont généralement une idée fausse de la notion de qualité dans le fameux triptyque du chef de projet Coût – Délai – Qualité.

En m’appuyant sur ma double expérience en tant que chef de projet informatique et en tant que responsable assurance qualité, je vais essayer de bien vous faire comprendre cette notion essentielle à la réussite d’un projet.

En premier lieu, il est important de comprendre que la notion de qualité, qui doit s’utiliser dans le cadre de la réalisation d’un projet informatique, n’est pas la notion qui est utilisée par tout le monde dans la vie courante.

Ainsi, faire de la qualité, dans un projet informatique, ce n’est pas faire un produit beau et parfaitement fiable qui est été peaufiné dans ses moindres détails (ce n’est pas un sac à main Louis Vuitton 😉 ). Faire de la qualité c’est, en premier lieu, répondre aux attendus du projet c’est-à-dire respecter les demandes du client telles qu’elles ont été définies lors de l’élaboration du cahier des charges. Ensuite, c’est aussi faire un produit qui soit fonctionnel, ergonomique et avec un minimum de bugs.

Je vois déjà certaines personnes qui vont me dire que faire de la qualité, c’est ne laisser aucun bug dans son projet. Mais, dans la pratique, à part pour quelques petits projets, il est quasiment impossible de pouvoir certifier que dans le projet qu’on livre, il ne reste pas de bugs. Si on veut vraiment pouvoir l’assurer, il faudrait utiliser des méthodes ou des langages de développement spécifiques, comme le langage B, qui permet de vérifier, mathématiquement parlant, qu’un programme n’a aucun bug. Ce qui est rarement le cas étant donné les contraintes et les limites de ce type de méthodes et langages. D’ailleurs connaissez-vous un programmeur en langage B ?

Pour ce qui est de la vérification de la qualité du produit livré par rapport aux spécificités du cahier des charges, celle-ci est facilement réalisable en effectuant un pointage minutieux de tous les attendus sur le produit livré. Se pose alors la question de la pertinence et de l’exhaustivité du contenu du cahier des charges. Si celui-ci est incomplet ou si les besoins ont été mal exprimés ou mal traduits, le produit livrés pourra être, dans l’absolu, un produit de qualité bien qu’inutilisable. C’est d’ailleurs bien là tout le paradoxe de la qualité dans un projet informatique. D’où, comme nous le verrons dans un autre article, l’importance du cahier des charges pour la bonne réalisation d’un projet ; celui-ci pouvant prendre différentes formes.

Dans un projet, si la qualité concerne de manière générale le produit livré, elle s’applique aussi aux méthodes utilisées pour le réaliser. En effet, si le projet est un projet de qualité, car répondant à tous les attendus du cahier des charges, mais qu’il a été réalisé, techniquement parlant, de manière totalement anarchique, il ne sera bien-sûr pas possible de dire que celui-ci est de qualité. Alors qu’entend-t-on par qualité de réalisation dans un projet ?

Si on prend, pour des raisons de simplicité, l’exemple d’un projet de développement, avoir une réalisation de qualité signifiera que :

  • L’équipe de développement a organisé son code pour qu’il soit parfaitement lisible.
  • L’équipe de développement a utilisé une norme pour le codage qui se rapproche, autant que possible, des normes utilisées par les autres projets déjà réalisés au sein de la société.
  • L’équipe de développement a documenté la partie technique du projet afin de permettre sa reprise rapide par d’autres personnes.
  • L’équipe de développement a défini, de manière formelle, l’environnement technique nécessaire à la reprise du produit par d’autres personnes.
  • Tous les documents produits par l’équipe projet sont complets et facile à lire et à comprendre.

Enfin, si un projet respecte tous les critères de qualité énoncés précédemment mais que le produit livré n’est pas réellement utilisable au quotidien par manque d’ergonomie ou par manque de performance, celui-ci ne pourra pas être considéré comme ayant atteint les objectifs de qualité. Sur ce point, il existe de nombreuses méthodes et outils qui permettent à un chef de projet de s’assurer du bon niveau de qualité de son produit avant que celui-ci ne soit livré aux utilisateurs. Ceux-ci seront présentés dans d’autres articles de ce blog au fil du temps.

Pour résumer, la notion de qualité est une notion complexe qui recouvre de nombreux aspects différents. Ceci étant, elle est essentielle à la bonne réalisation d’un projet car, c’est un des éléments fondamentaux qui permet de pouvoir s’assurer de la réelle réussite d’un projet.

Publié dans Qualité | Marqué avec | Commentaires fermés sur Coût – Délai – Qualité : La qualité

Coût – Délai – Qualité : Les délais

Publié le 3 septembre 2014 par AdminArnaudBrossard
Les délais dans un projet informatique

Les délais dans un projet informatique

Parler de délais pour un projet informatique peut sembler, au premier abord, assez simple. En effet, si on prend la définition de base, le délai sur un projet informatique représente le temps entre la date de démarrage du projet et la date de mise en production du projet. Mais est-ce vraiment aussi simple ?

En premier lieu, il est important de savoir, pour le projet, si le délai a été fixé par rapport à des impératifs de date ou par rapport à d’autres contraintes comme une limitation des coûts.

Dans le cas où il y aurait un impératif de date, une solution éprouvée pour organiser un projet consiste à prévoir toutes les étapes du projet en partant de cette date imposée pour revenir à une date de démarrage du projet. De cette manière, il devient possible de mieux définir les ressources nécessaires à la bonne réalisation du projet mais aussi de bien poser les différents jalons du projet qui permettront de déterminer rapidement si celui-ci pourra ou pas être livré dans les délais fixés.

Si l’impératif de délais est fixé par rapport à d’autres contraintes, le chef de projet devra d’abord penser à organiser son projet en fonction des autres contraintes puis l’adapter pour tenir compte des contraintes fixées sur les délais. Cela ne veut pas dire que la prise en compte des délais n’est pas importante pour la mise en place du projet mais qu’elle est secondaire ; d’autres priorités devant être d’abord prises en compte.

Si maintenant, on demande au chef de projets de définir les délais de son projet, celui-ci devra alors se lancer dans la difficile tâche de l’estimation de l’ensemble des charges associées à son projet. Pour cela, il devra être en mesure de faire une estimation des délais de réalisation de chaque étape de son projet en prenant compte des expériences passées, des règles de bonne pratique en matière d’estimation des projets et surtout des compétences et de l’implication des personnes qui vont être affectées au projet.

Ce dernier point est certainement le point le plus important dans le sens où, sans connaître l’équipe projet il est difficile de faire une estimation fiable. En effet, si on prend un développeur informatique, entre un développeur peu compétent (par manque d’expérience ou autre) et un développeur très compétent, il peut exister un rapport de 1 à 4 en matière de productivité ; ce qui aura une influence énorme sur les délais de réalisation du projet.

Ensuite, sauf à avoir déjà réalisé plusieurs projets similaires dans le passé, il est souvent très difficile d’estimer les délais de réalisation de chaque phase du projet par manque de retour d’expérience et aussi, parfois, par manque de connaissances techniques sur les difficultés qui pourront être rencontrées pendant le projet.

Alors est-il vraiment possible d’estimer les délais de réalisation d’un projet ?

Dans la pratique, la réponse est oui, si on prend en compte une marge de sécurité suffisante sur chaque étape et chaque phase et si on se base sur un certain nombre d’hypothèses de travail qui semblent cohérentes par rapport à l’environnement du projet (exemple : prendre comme hypothèse que les développeurs seront des développeurs moyens).

Ceci signifie que le chef de projet doit être en mesure de prévoir l’imprévu ; cette part d’imprévu devant être aussi réduite que possible pour que l’estimation des délais puisse être la plus réaliste possible. C’est d’ailleurs souvent sur cette partie qu’on distingue le chef de projet expérimenté du chef de projet débutant ; l’expérience étant un atout de taille à ce niveau.

Si, pendant la réalisation de son projet, le chef de projet voit que les délais ne pourront pas être respectés par rapport au planning initial, il aura souvent plusieurs solutions à sa disposition :

  • Demander un décalage du projet dans le temps et donc une augmentation des coûts du projet : C’est la solution qu’il convient de mettre en oeuvre lorsque les autres solutions ne permettent pas de revenir aux délais initiaux.
  • Demander à revoir le contenu du projet : Ne pas faire tout ce qui était prévu initialement, tout en gardant un tout cohérent, peu permettre de tenir les délais
  • Réorganiser les phases suivantes du projet : L’objectif, à ce niveau, est de trouver comment regagner du temps sur les phases suivantes du projet pour le remettre sur la phase en cours qui va demander plus de temps.
  • Abandonner le projet : Si, suite à une analyse ou à une étude préliminaire incomplète, on se rend compte que le projet va être très largement hors délais, la question devra se poser de savoir s’il est toujours ou pas pertinent de le mener à son terme. Si la réponse est oui, le chef de projet devra réorganiser le projet en fonction de nouveaux délais qui seront en adéquation avec la réalité du projet. Savoir abandonner un projet à temps fait partie des qualités attendues d’un bon chef de projet.

Dans la gestion quotidienne du projet, le chef de projets devra suivre les délais au quotidien pour être en mesure de mettre en place, le plus rapidement possible, les mesures nécessaires pour remédier au plus vite à tout retard qui pourrait pénaliser le projet. Dans un projet, les problèmes ont, en effet, plus tendance à s’accumuler  qu’à se résoudre tout seuls. Et, s’ils ne sont pas traités au fur et à mesure, le projet peut vite déraper. Sur ce point, je vous expliquerai, dans d’autres articles, comment faire pour limiter les risques sur un projet et pour le mener à son terme.

Publié dans Délai | Marqué avec | Commentaires fermés sur Coût – Délai – Qualité : Les délais

Coût – Délai – Qualité : Les coûts

Publié le 3 septembre 2014 par AdminArnaudBrossard
Les coûts d'un projet informatique

Les coûts d’un projet informatique

Dans un projet informatique, la notion de coût peut recouvrir de nombreux aspects qu’il convient ou pas de prendre en compte en fonction du périmètre du projet.

Si on ne veut pas entrer dans une approche comptable des coûts d’un projet, il est possible de les déterminer très simplement en prenant en compte les différentes étapes de la vie d’un projet. Ainsi, on a :

  • Les coûts liés à la phase d’initialisation et d’analyse du projet
  • Les coûts liés à la phase de développement du projet
  • Les coûts liés à la phase de validation du projet
  • Les coûts liés à la phase de mise en oeuvre du projet
  • Les coûts liés à la phase d’exploitation du projet
  • Les coûts liés à la phase d’arrêt d’exploitation du projet

Et, comme nous allons le voir ci-dessous, prendre en compte tous les coûts liés à un projet nécessite souvent d’être en mesure de faire une analyse multi-domaines et multi-métiers.

Attention : Je n’ai pas la prétention de vous donner ici la liste de tous les coûts possibles pour un projet informatique mais de vous donner une idée des principaux coûts à prendre en compte pour savoir évaluer le coût total d’un projet informatique. En parallèle de cette présentation des coûts, un autre article présentera comment il est possible de calculer un retour sur investissement (ROI) sur un projet informatique.

Les coûts liés aux ressources humaines

Dans toutes les phases d’un projet informatique, les coûts associés aux ressources humaines peuvent être évalués de la même manière. Ce sont :

  • Les coûts salariaux qui sont associés directement au salaire de chaque personne travaillant sur le projet (le passage à un coût journalier ou à un coût horaire doit s’envisager en fonction du type de projet et en fonction du type d’intervenant)
  • Les coûts des prestations complémentaires qui sont associés directement au montant des prestations demandées par un ou plusieurs intervenants externes à la société sur un projet comme un expert technique ou un graphiste indépendant.
  • Les coûts associés à de la formation lorsqu’il est nécessaire d’envoyer des personnes de l’équipe projet en formation technique ou fonctionnelle pour la bonne réalisation du projet. Ces coûts comprennent aussi les éventuels coûts associés à la participation à des séminaires en lien avec le projet.
  • Les coûts associés aux déplacements lorsque des personnes du projet doivent se déplacer pour participer à des réunions ou pour réaliser des séances de travail.
  • Les coûts associés à un éventuel manque à gagner lorsque, par exemple, un expert métier travaille sur un projet plutôt que de générer directement des revenus pour la société.
  • Les coûts associés à un éventuel remplacement de la personne à son poste pendant la période pendant laquelle elle est affectée au projet (ce coût ne devant être pris que partiellement en compte étant donné que le salaire de la personne affectée au projet est déjà pris en compte.
  • Les coûts associés à des indemnités ou à des primes de fin de projet (exemple : recrutement de personnes en CDD sur le projet, primes d’objectifs spécifiques, gratifications complémentaires, etc.).

Les coûts liés à la phase d’initialisation et d’analyse du projet

Les coûts liés à la phase de mise en oeuvre d’un projet sont principalement des coûts liés aux ressources humaines qui peuvent être associés à l’ensemble du temps passé par les personnes des différents services ou entités pour définir ce que doit être le projet (réunions de travail pour définir les besoins, interview réalisées dans le cadre de l’élaboration du cahier des charges, rédaction et validation du cahier des charges, appel à de l’expertise technique ou à de l’expertise métier, etc.).

A ces coûts humains peuvent aussi s’associer, dans certains projets, des coûts techniques liés à la mise en oeuvre d’un prototype (un POC ou Proof Of Concept) qui peut nécessiter l’utilisation de moyens techniques (serveurs, réseaux, etc.). Sur ce point, il est important de noter qu’un POC est à lui seul un petit projet pour lequel il est possible de déterminer un coût global de la même manière que pour un projet.

Les coûts liés à la phase de développement du projet

Les coûts liés à la phase de développement du projet sont souvent principalement les coûts liés aux ressources humaines affectées au projet pendant cette phase (un autre article présentera en détail toutes les personnes intervenant dans cette phase).

A ces coûts peuvent s’associer des coûts liés à la mise en place d’un environnement technique pour la réalisation des développements et d’un autre pour la réalisation des tests unitaires.

Les coûts liés à la phase de validation du projet

Les coûts liés à la phase de validation du projet sont, là encore, des coûts majoritairement liés aux ressources humaines associées au projet (un autre article présentera en détail toutes les personnes intervenant pendant cette phase).

A ces coûts peuvent s’associer les coûts liés à :

  • la mise en place d’un environnement technique pour la réalisation des tests de validation du projet
  • La réalisation des documentations techniques pour la mise en production et la mise en exploitation du projet.
  • La réalisation des documentations fonctionnelles pour les utilisateurs avec la conception des éventuelles formations associées avec leurs supports de cours.

Les coûts liés à la phase de mise en production du projet

Dans cette phase, on retrouvera encore tous les coûts liés aux ressources humaines qui sont sollicités pour sa bonne réalisation.

Mais, on trouvera aussi :

  • Les coûts liés à la mise en place de l’environnement technique de production
  • Les coûts associés à la formation des personnes qui seront en charge de l’exploitation du produit
  • Les coûts liés à la conduite du changement au sein de l’entreprise pour s’adapter aux nouveaux produits ou aux nouveaux services en lien direct avec le projet
  • Les coûts associés à la formation des utilisateurs (location de salles de formation, coûts des formateurs, coûts liés au temps de formation de chaque personne (salaire, manque à gagner, etc.)
  • Les coûts de communication sur le nouveau produit auprès des utilisateurs

Les coûts liés à la phase d’exploitation du projet

Au niveau de cette phase, si on retrouve toujours les coûts liés aux ressources humaines en lien avec le projet, il existe aussi une séparation assez nette entre deux types de coûts différents.

Ainsi, on trouve les coûts liés à la maintenance du projet :

  • Les coûts liés à la maintenance corrective du produit (correction des bugs détectés en production)
  • Les coûts liés à la maintenance évolutive récurrente sur le produit (exemple : remise à jour annuelle pour tenir compte des évolutions légales ou en matière de gammes de produits ou services proposés à la vente)
  • Les coûts liés à la maintenance évolutive non récurrente sur le produit peuvent, dans certains cas, être évalués à l’avance sous la forme, par exemple, d’une enveloppe annuelle d’évolution. Mais, bien souvent, ces coûts sont difficilement quantifiables a priori. Ceci étant, il est important de les suivre pendant la première année après la mise en production d’un projet car ceux-ci peuvent être significatifs pour détecter une analyse ou une réalisation incomplète ou imparfaite du projet ; ce qui permettra de limiter les risques de reconduire les mêmes problèmes sur un nouveau projet.

Mais aussi les coûts liés à l’exploitation du projet, c’est-à-dire à son utilisation quotidienne :

  • Les coûts en ressources humaines associés aux personnes en charge de gérer et de surveiller le bon fonctionnement du projet au quotidien
  • Les coûts techniques associés soit au remplacement du matériel utilisé par le projet en cas de panne ou d’obsolescence soit à la montée en puissance du projet (ajout de nouveaux serveurs, ajout de nouveaux disques, etc.).
  • Les coûts des contrats de maintenance associés au matériel
  • Les coûts associés à d’éventuelles assurances complémentaires (perte de données, perte d’image de marque, etc.)

Les coûts liés à la phase d’arrêt d’exploitation du projet

En-dehors des coûts liés aux ressources humaines associées à cette phase, les coûts d’arrêt d’exploitation du projet sont :

  • Les coûts des éventuelles solutions techniques qui doivent être mises en oeuvre pour conserver des historiques accessibles pendant une durée déterminée
  • Les coûts associés à la conservation des connaissances et du savoir-faire technique sur le projet
  • Les coûts de la communication effectuée auprès des utilisateurs sur l’arrêt du produit
  • Les coûts de retraitement du matériel (si nécessaire)

Les autres coûts à prendre ou pas en compte en fonction du contexte

A côté de tous les coûts qui viennent d’être présentés, il existe d’autres coûts, un peu plus cachés, qu’il peut être intéressant ou pas de prendre en compte en fonction du contexte du projet. Ces coûts sont :

  • Les coûts des matériels mis à disposition de l’équipe projet pendant la durée de réalisation du projet (matériel informatique, mobilier, matériel de bureau, etc.).
  • Les coûts des locaux mis à disposition de l’équipe projet pendant la durée de réalisation du projet.
  • Les coûts des consommables utilisés par l’équipe projet pendant la durée de réalisation du projet (cartouches d’encre, capsules de café, etc.).
  • Les coûts en matière de consommation d’énergie (électricité, gaz, etc.), de fluides (eau, etc.) et de communication (télécommunications, etc.) pendant toute la durée de réalisation du projet.
Publié dans Coût | Marqué avec | Commentaires fermés sur Coût – Délai – Qualité : Les coûts

Le triptyque Coût – Délai – Qualité

Publié le 2 septembre 2014 par AdminArnaudBrossard
Le triptyque Coût - Délai - Qualité, l'ABC du chef de projet

Le triptyque Coût – Délai – Qualité, l’ABC du chef de projet

Lorsqu’on parle des grands principes d’un projet, qu’il soit lié à l’informatique ou pas, on cite souvent le triptyque coût – délai – Qualité comme étant les 3 axes qu’il faut savoir maîtriser pour mener son projet à bien. Et, ce n’est pas loin de la vérité.

En effet, si le projet est d’excellente qualité, mais qu’on fait exploser les coûts, il est probable qu’il ne soit pas possible de le terminer ou alors qu’on ne puisse jamais obtenir un retour sur investissement.

De même, si on doit livrer un projet à une date précise, par exemple un site web spécifiquement conçu pour les fêtes de fin d’année, et qu’on le livre en retard, en janvier  pour notre site web, il est possible que celui-ci ne serve plus à rien au final où que le décalage entraîne des coûts ou des pertes importantes pour le commanditaire du projet.

On pourrait ainsi multiplier les exemples où ne pas respecter un ou plusieurs de ces éléments du triptyque aurait des conséquences importantes sur la bonne marche du projet.

Mais, tout n’est pas aussi simple que ça car les notions de Coût, de Délai et de Qualité recouvrent beaucoup d’autres choses que je détaillerai dans plusieurs autres articles.

Ce qu’il est important de bien comprendre, lorsqu’on est chef de projet ou lorsqu’on est en passe de le définir, c’est que notre fameux triptyque doit sans cesse être revu et adapté en fonction des événements.

Ainsi, on se rend compte, en cours de projet, qu’en investissant x euros supplémentaires il est possible de doubler ou de tripler le retour sur investissement du projet, il serait vraiment dommage de ne pas revoir ses plans.

De même, si en réduisant le périmètre du projet et en augmentant sa qualité, il est possible de générer un plus haut degré de satisfaction des utilisateurs, il est possible que cela s’avère beaucoup plus intéressant au final.

Enfin, si en augmentant un peu les délais de livraison, il est possible de profiter de nouvelles technologies qui vont entraîner des gains importants dans l’exploitation quotidienne du projet, il faut se poser la question de savoir s’il ne vaut pas mieux profiter de cette nouvelle possibilité plutôt que de tenir absolument des délais.

Ceci étant, dans un projet, il est rare qu’un des trois axes (Coût – Délai – Qualité) n’ait pas de contraintes fortes qui empêchent de le faire varier. Et, quand ce sont les trois axes qui ont des contraintes fortes, la gestion du projet devient souvent plus complexe tout en nécessitant plus de compétences de la part du chef de projet.

Au final, un bon chef de projet n’est pas celui qui respecte, de manière doctrinaire, tous les critères de Coût, de Délai et de Qualité, mais celui qui est capable de jongler en permanence avec ces critères pour que son projet aboutisse, mais surtout pour qu’il tienne compte du contexte pour apporter le meilleur résultat possible pour le client.

Si ceci est valable pour un chef de projet dans une société finale, il faut aussi reconnaître que cette adaptation ne se fait pas de la même façon lorsque le chef de projet travaille au forfait pour un client pour une SSII. Si les critères restent les mêmes dans l’absolu, les priorités sont bien souvent différentes comme nous le verrons dans un autre article.

Publié dans Coût, Délai, Qualité | Marqué avec , , | Commentaires fermés sur Le triptyque Coût – Délai – Qualité

Qui est le vrai client de mon projet ?

Publié le 22 août 2014 par AdminArnaudBrossard
A la recherche de mon client

A la recherche de mon client

La réponse peut sembler évidente, au premier abord, mais c’est loin d’être le cas dans la réalité.

En premier lieu, il faut commencer par comprendre la différence entre le demandeur d’un projet informatique et l’utilisateur final :

  • Le demandeur, c’est la personne, ou l’entité, qui va demander à réaliser (qui va commander) un projet informatique
  • L’utilisateur final, c’est la personne qui va utiliser ce qui va être produit par le projet informatique.

Si on prend l’exemple d’un développement d’un site web de type e-commerce qui serait confié, par une société commerciale, à une agence web, le demandeur serait la société commerciale et l’utilisateur final, un client de cette société commerciale.

Alors, qui doit-on devoir réellement satisfaire ? Le demandeur ou l’utilisateur final ?

La réponse la plus simple serait de dire que c’est toujours le demandeur qu’il faut chercher à satisfaire en premier et que c’est donc lui l’unique client du projet.

Mais, si on y regarde de plus près, si on travaille pour une société finale, c’est-à-dire que le projet est à destination de la société, ne pas tenir compte des utilisateurs finaux aura toujours, pour finir, des répercussions soit économiques soit en matière d’image. Car, il ne faut pas oublier que, pour une entreprise, le vrai client est celui qui achète les produits ou les services de l’entreprise et pas les services internes de l’entreprise.

Si on travaille pour une société de service ou une agence web qui a reçu une commande, ce n’est, a priori, pas très grave du moment que, du point de vue contractuel, le projet répond point par point aux spécifications du demandeur et donc que le contrat a été respecté. Mais, à l’avenir, le demandeur ne risque-t-il pas de ne plus jamais nous confier de projets ?Et l’image de marque de notre société ne risque-t-elle pas d’être fortement ternie auprès de nos autres entreprises clientes actuelles et potentielles qui font partie du réseau de relation du demandeur ?

La réponse que doit apporter un bon chef de projet à cette question est d’essayer, dans le cadre de la réalisation de son projet, de satisfaire aussi bien le demandeur que les utilisateurs. C’est-à-dire de satisfaire tous les clients ; le demandeur étant le client du chef de projet et l’utilisateur final étant le client du demandeur.

Si, en tant que chef de projet, vous n’avez pas accès directement aux utilisateurs, votre premier travail consistera à faire prendre conscience, au demandeur, de la nécessité d’élaborer le cahier des charges, mais aussi de prévoir des tests d’intégration en lien avec des personnes représentatives des utilisateurs finaux.

Si vous avez la possibilité d’avoir accès directement à ces utilisateurs finaux, ce sera à vous de les intégrer dans les différentes étapes de votre projet informatique et donc de prendre en charge la notion de client de manière globale..

De tout cela, vous devez retenir que l’implication des demandeurs et des utilisateurs est essentielle à la réalisation de tout projet informatique. Si vous ne le faites pas, vous augmenterez de manière très significative les risques sur votre projet que ce soit sur les coûts, les délais ou la qualité.

Savoir comment impliquer au mieux les demandeurs et les utilisateurs dans un projet fera l’objet d’un autre article…

Publié dans Client | Marqué avec , , | Commentaires fermés sur Qui est le vrai client de mon projet ?