Planification et architecture de l’implémentation

Effectué

La première étape de tout projet est également la plus importante : la planification. Et un excellent moyen de planifier consiste à commencer à concevoir les phases, puis à ajouter les échéanciers, les activités, les ressources, les livrables, etc. Des méthodologies vous permettent de structurer tous ces éléments du projet de manière visible, compréhensible et facile à suivre pour toute l’équipe.

Une méthodologie est une technique formelle dotée de procédures structurées de manière ordonnée et complète. Une séquence correcte des tâches et la garantie que toutes les ressources et artefacts requis sont correctement gérés tout au long du cycle de vie de votre projet sont essentielles pour une implémentation réussie.

Lors d’une implémentation d’applications de finances et d’opérations, l’investissement client augmente dans le temps, indépendamment de la méthodologie ou du modèle utilisé(e). Mais réduire le délai de prise en main et créer de la valeur pour le client est un objectif. Vous pouvez planifier une seule mise en service et commencer à être en opération avec toutes les fonctionnalités en une seule fois. L’autre option consiste à publier les fonctionnalités en production en plusieurs déploiements (plusieurs mises en service).

Schéma illustrant à la fois l’option de mise en service unique et les options de déploiements multiples.

Méthodologies itératives et en cascade

Il est important de sélectionner la méthodologie adéquate pour votre projet d’implémentation d’applications de finances et d’opérations en fonction de la solution métier et en tenant compte du délai de rentabilisation. Nous présentons ici les méthodologies les plus utilisées dans le cadre de ces implémentations.

Méthodologie en cascade

La méthodologie en cascade est une approche séquentielle. Le projet est divisé en différentes phases qui vont de la phase précédente à la phase suivante jusqu’à la fin du projet. Chaque phase est entièrement documentée avec des livrables, des examens et des approbations clairs. En général, la phase suivante de la méthodologie Waterfall ne démarre pas avant la fin de la phase précédente. Par exemple, si vous deviez implémenter des applications de finances et d’opérations, toutes les exigences pour chaque intégration devraient être définies avant que les développeurs puissent commencer le développement.

En général, ces projets ont de longs échéanciers, voire plusieurs mois d’activités de conception et de création. Ils peuvent présenter des problèmes d’altération des besoins, d’atrophie des connaissances et d’incertitude accrue concernant les phases suivantes. De plus, des problèmes sont souvent détectés tardivement après l’exécution du développement et des tests, et peuvent se répartir sur plusieurs cycles de test, allongeant ainsi les délais et retardant le projet.

Schéma illustrant la méthodologie Waterfall.

La méthodologie Waterfall doit être envisagée lorsque le projet est simple, que les besoins sont connus et bien définis, que le périmètre total du projet n’est pas destiné à changer et que le projet est implémenté en une seule fois.

Méthodologie itérative

Une méthodologie itérative se concentre sur un feedback continu pour modifier des livrables et en ajouter au projet. Contrairement à la méthodologie en cascade, les phases itératives peuvent se reboucler. Autrement dit, il est possible de travailler simultanément sur différentes phases.

Par exemple, si des besoins sont définis pour une intégration, les développeurs peuvent commencer à travailler sur cette intégration, même si d’autres intégrations se trouvent encore dans une phase de collecte des besoins. En général, les projets itératifs sont divisés en sprints, qui ont une durée définie (généralement une ou deux semaines). Ces sprints ont une liste de livrables à terminer pendant leur durée.

L’approche itérative est utile si les besoins ne sont pas clairs au démarrage du projet, si des besoins ou livrables supplémentaires sont attendus au cours du cycle de vie de l’application ou si le projet ne doit pas être publié en une seule fois. Cette approche est également recommandée pour les projets axés sur l’utilisateur, surtout si l’équipe de projet est entièrement dédiée au projet. Comme l’approche itérative implique de nombreux acteurs qui travaillent simultanément sur différentes parties du projet, la communication et la coordination du projet peuvent être difficiles. Par conséquent, il est avantageux d’avoir l’équipe de projet en contact régulier.

Lors de chaque sprint, vous pouvez avoir du feedback et une validation, détecter tout problème potentiel tôt dans le processus, acquérir plus de connaissances grâce à la répétition et créer des développements avec plus de confiance.

Cette méthodologie peut être complexe à suivre en raison de sa nature itérative. Les priorités sont souvent redéfinies pour le travail à réaliser lorsque les livrables dépassent le sprint d’origine ou si de nouveaux sprints doivent être ajoutés ultérieurement.

Cette méthodologie comporte d’autres risques : avoir plus d’activités en parallèle, nécessiter plus de ressources client et perturber davantage une organisation en faisant face à des défis de gestion du changement. L’étendue peut glisser d’une itération à l’autre.

Schéma illustrant la méthodologie itérative.

Lors de la planification, il est important d’utiliser la méthodologie adéquate, selon les phases, la durée, la qualité et le budget du projet.