Lorsque l’équipe a du mal à se mettre d’accord sur la justification du projet, voici quelques paramètres à prendre en compte pour trouver le bon compromis.
Project Justification: Trade-off Options
https://www.bonniebiafore.com/project-justification-trade-off-options/ par Bonnie Biafore
La justification d’un projet n’est pas toujours évidente. Cela pourrait nécessiter de longues négociations pour répondre à des besoins commerciaux contradictoires. Et cela peut aller au-delà de la triple contrainte du coût, du contenu et du temps.
Lorsque l’équipe a du mal à se mettre d’accord sur la justification du projet, voici quelques paramètres à prendre en compte pour trouver le bon compromis.
#1 – Ressources par rapport à la date de fin du projet.
Les exigences d’un projet s’accompagnent souvent d’échéances de temps prédéfinies et agressives. L’ajout de ressources, y compris l’embauche de compétences spécialisées, est un moyen de respecter ces délais. Gardez à l’esprit que, même avec plus de ressources, des délais serrés peuvent augmenter les risques car le calendrier est plus sensible aux changements de ressources et aux problèmes d’achèvement des tâches.
#2 – Utilisation d’une configuration ou de personnalisations prêtes à l’emploi lors de la mise en œuvre d’un logiciel.
Les produits logiciels sont souvent accompagnés d’un ensemble standard de processus métier qu’ils prennent en charge. Cette approche « prête à l’emploi » de la mise en œuvre d’un logiciel est la plus simple et la moins coûteuse. La plupart des progiciels fournissent également des fonctionnalités permettant de 
configurer le produit, ce qui offre la flexibilité nécessaire pour prendre en charge divers processus métier. Bien que la configuration soit plus coûteuse et plus longue que l’utilisation d’un logiciel prêt à l’emploi, la configuration peut améliorer l’efficacité et l’efficience de l’entreprise. Sinon, les entreprises peuvent choisir de personnaliser le logiciel pour répondre à des processus spécifiques ou uniques. La personnalisation est coûteuse et comporte des risques inhérents, tels que la compatibilité avec les futures mises à jour logicielles du fournisseur. Faites le choix conscient de l’utilisation d’une configuration prête à l’emploi ou d’une configuration.
Réservez la personnalisation aux cas où l’entreprise s’appuie sur des processus propriétaires et uniques qui nécessitent un support logiciel sur mesure.
#3 – Livrez par phases plutôt que d’exécuter un seul grand projet.
De nombreuses parties prenantes soumettent un large éventail d’exigences de projet. Bien qu’elles soient toutes utiles, vous n’aurez peut-être pas besoin de certaines pour offrir des avantages business. Le découpage d’un projet en phases signifie que vous pouvez créer de la valeur plus tôt. 
Cela réduit également les risques, en particulier lorsque les membres de l’équipe de projet ont des responsabilités opérationnelles quotidiennes. Un projet plus long signifie qu’il est plus probable que les membres clés de l’équipe soient retirés à certains moments pour répondre aux besoins opérationnels. Enfin, lorsque l’entreprise est préoccupée par les coûts, opter pour un projet plus petit est utile. La phase initiale du projet coûtera moins cher. De plus, les parties prenantes examineront de près les exigences pour les phases futures du projet, car elles auront besoin d’une analyse de rentabilisation séparée de celles-ci. Enfin, à mesure que les conditions business changent, une exigence apparemment importante peut ne plus être aussi cruciale.
#4 – Qualité versus rapidité.
La qualité par rapport à la vitesse est un compromis puissant mais risqué. Bien sûr, vous pouvez réduire le coût du projet et livrer les produits plus rapidement en utilisant moins de processus d’assurance qualité. Cependant, le coût du projet peut augmenter si les produits livrés comportent des erreurs qui affectent l’entreprise ou, pire encore, les clients de votre entreprise. Ce compromis est souvent fait tard dans un projet, lorsque les délais sont menacés et que les équipes sont désespérées de pouvoir livrer à temps. Discutez de cette possibilité de compromis à l’avance, avant que la pression des délais ne soit présente. Négociez pour maintenir les processus d’assurance qualité nécessaires pour protéger l’entreprise contre les erreurs coûteuses.
#5 – Maintenance à long terme par rapport au développement initial.
Dans les projets de développement de produits, une décision cruciale consiste à identifier les activités de maintenance continues requises une fois le projet terminé et le produit utilisé quotidiennement. Vous pouvez minimiser la maintenance du produit en investissant plus d’efforts, d’argent et de temps pendant le développement. Le développement d’un produit plus simple peut être plus rapide et moins coûteux, mais il peut augmenter l’effort de maintenance et le coût d’utilisation à long terme. 
Par exemple, vous pouvez construire une machine autolubrifiante, ce qui serait plus coûteux. Si vous n’optez pas pour cette solution, l’entretien consistera à s’assurer qu’il y a suffisamment de lubrifiant pour que la machine fonctionne correctement. La machine la plus simple coûterait moins cher à construire. Mais alors, cela nécessiterait des efforts, des ressources et des temps d’arrêt pendant que la machine est périodiquement démontée et lubrifiée manuellement. En collaboration avec les concepteurs de produits, les managers de projet peuvent identifier le coût total de possession pour négocier l’approbation du projet.
_______________________________________
Cet article fait partie de Bonnie’s Project Pointers newsletter
DantotsuPM.com 