“On n’exécute pas tout ce qui se propose ; Et le chemin est long du projet à la chose”
Jean-Baptiste Poquelin, dit Molière
Qu’est-ce que le périmètre d’un projet ?
Le périmètre d’un projet est une composante fondamentale du triangle d’or, également connu sous le nom de triple contrainte, comprenant le coût, les délais et le périmètre, où chacun influence les deux autres.
Il représente essentiellement ce que le projet doit accomplir, soit le “QUOI”.
Ce périmètre est défini par les exigences qui détaillent les attentes du projet.
Les exigences correspondent aux besoins des utilisateurs finaux exprimés par le client et doivent être satisfaites par le produit.
Elles englobent les fonctionnalités ou services attendus, les normes à respecter et les dépendances à considérer, telles que les services tiers.
En fonction du modèle de développement utilisé (cycle en V, séquentiel, itératif ou Agile), le référentiel des exigences ou le backlog initial du produit matérialisent le périmètre.
Le périmètre joue un rôle crucial en guidant le travail des équipes tout au long de l’exécution du projet, en les aidant à rester sur la bonne voie et à éviter les dérives potentielles.
Acter le périmètre
Le périmètre d’un projet représente le principal élément de dimensionnement de la phase d’Avant-Vente, influençant ainsi le dispositif proposé au client, y compris les charges, le budget, les délais, les engagements et le niveau de risque.
Il est étroitement lié à la proposition commerciale et en justifie une grande partie.
Le périmètre, souvent matérialisé par un référentiel d’exigences, est également une composante cruciale du Plan Projet et peut être annexé au contrat avec le client. Dans certains cas, il peut être formalisé sous la forme d’un Cahier des Charges.
Ces documents de cadrage sont soumis à la validation du client.
Qualité du périmètre
Plus les exigences formulées par le client sont exhaustives et précises, meilleures seront les estimations en phase d’Avant-Vente.
Ainsi, le chiffrage reposera sur des hypothèses claires et documentées, garantissant à l’entreprise un engagement juste et bien encadré.
Cependant, l’expression des besoins du client n’est pas nécessairement contraignante.
Certaines exigences peuvent être écartées (en raison de leur faisabilité discutable, de leur pertinence mineure ou proposées en option pour des raisons de coût), ou bien ajustées à la hausse ou à la baisse en termes d’ambition.
Il est essentiel d’identifier clairement les exigences qui ne seront pas traitées telles quelles ou du tout, et d’informer explicitement le client de leur exclusion du périmètre couvert par le prestataire de service et de sa responsabilité.
Ce sont les exigences auxquelles le prestataire de service répond avec ses propres hypothèses structurantes qui, une fois validées par le client, définiront le périmètre du projet, plutôt que l’expression initiale des besoins.
Exigences et approche produit
Les exigences, généralement fonctionnelles pour répondre aux besoins des utilisateurs finaux, doivent être considérées de manière holistique à la fois en Avant-Vente et en Delivery, car “Le diable se cache dans les détails“. Dans cette optique, il est essentiel de prendre en compte :
La valeur business pour prioriser voire segmenter les éléments.
- L’utilisabilité, notamment l’expérience utilisateur (UX), les interfaces utilisateur (UI), les appareils, les langues, etc.
- La fiabilité, incluant la stabilité et la disponibilité du produit.
- La performance, couvrant le temps de réponse, la volumétrie des données, le nombre d’utilisateurs, etc.
- La sécurité, en adoptant une approche de sécurité dès la conception (Security By Design).
- La conformité réglementaire, notamment en ce qui concerne la RGPD.
- L’impact RSE (Responsabilité Sociétale des Entreprises) : l’écoconception, l’accessibilité, la conformité, etc.
- La maintenabilité à travers l’architecture, la configuration, les normes, la documentation, etc.
Pour éviter que le périmètre ne devienne une liste indigeste d’exigences et pour le rendre directement exploitable par les opérationnels du projet, il est préférable d’adopter une approche produit.
Cela implique de décomposer le périmètre en sous-produits ou produits intermédiaires, avec une granularité adaptée au contexte : suffisamment détaillée pour former des ensembles fonctionnels cohérents et utilisables par les utilisateurs finaux, mais aussi assez fine pour réduire le délai de mise à disposition à ces utilisateurs.
L’approche produit se révèle également plus flexible lorsqu’il s’agit de réviser le périmètre avec le client et plus engageante pour l’ensemble des parties prenantes lors de la réalisation du projet.
Gérer les changements
Bien que le périmètre soit défini plus ou moins précisément au début du projet, il peut évoluer en raison de divers changements tels que des ajouts, des modifications, des substitutions ou des suppressions d’exigences, ainsi que la remise en cause d’hypothèses.
Ces changements peuvent être déclenchés par des facteurs externes au périmètre du produit, mais qui ont une influence sur celui-ci, comme :
- l’indisponibilité de parties prenantes
- le remplacement d’interlocuteurs
- de nouvelles réglementations
- des restrictions budgétaires
- des impacts conjoncturels
- des aléas de sécurité.
Il est important de noter qu’un tel changement est normal dans un projet complexe, incertain et évolutif, mais il est essentiel d’en mesurer les impacts et d’adopter la bonne démarche.
Le pilote de projet doit faire preuve de prudence dans la modification du périmètre et consigner tout changement apporté au cours du processus, généralement via des compte-rendus d’instances de gouvernance et/ou un registre des changements.
Il convient de rappeler que la triple contrainte s’applique : toute modification du périmètre peut avoir des répercussions sur le coût et les délais du projet, ainsi que sur son objectif ou sa qualité, surtout si elle entraîne des effets indésirables.
Dans le cadre d’une méthodologie prédictive telle que le Cycle en V, où le périmètre est initialement supposé être largement figé, sauf si le changement est compensable par un descopage ou négociable commercialement, le pilote de projet doit :
- Revisiter le plan projet et le contrat, en intégrant les mécanismes de gestion des changements.
- Qualifier et estimer les nouvelles exigences, tout en révisant celles qui en dépendent.
- Soumettre une nouvelle proposition au client, couvrant la charge supplémentaire.
- Mettre à jour le planning pour tenir compte de la dérive induite.
- Produire un avenant pour officialiser le changement.
- Obtenir la validation de l’ensemble de ces éléments avant leur mise en œuvre.
Dans le cadre d’un projet Agile, bien que l’adaptabilité au changement soit inhérente à la méthode, un changement n’est pas pour autant neutre en conséquences.
Le projet Agile est généralement délimité dans le temps (par exemple, un MVP minimum viable) et le budget est fixe.
Dans ce contexte, on privilégiera un système de troc pour absorber le changement, c’est-à-dire le remplacement de User Stories par d’autres ayant une même valeur en termes d’effort et donc de Story Points.
À défaut, le nombre de sprints financés pourra être étendu pour absorber le changement.
0 commentaires