De nombreux projets aboutissent à des échecs ou à des demi-succès. Quand on en analyse les causes, on s’aperçoit souvent que le périmètre d’un projet mal défini, ou de façon trop imprécise, est l’une des principales raisons de l’échec. Nous allons donc souligner ici l’importance du scope gestion de projet, et présenter l’intérêt qu’il y a à le définir de la façon la plus fine possible.
Qu’est-ce que le scope en gestion de projet ?
La définition du périmètre d’un projet consiste à définir précisément ce que doit contenir et prendre en compte le projet. Dans le cadre d’un projet informatique, il s’agit d’identifier l’ensemble des applications et des différents modules qui devront soit être créées lors du projet, soit impactées par le projet si ils existent déjà.
Le risque lorsque le périmètre du projet est mal défini, c’est qu’il faille prendre en compte de nouvelles fonctionnalités en cours de projet, et que les délais et les coûts augmentent de façon incontrôlée. Il est donc particulièrement important d’analyser en amont l’ensemble des besoins exprimés par le ou les clients, de façon à identifier le plus clairement possible les différentes fonctionnalités qui devront être prises en compte.
Il est important à ce stade de ne laisser aucune place au flou ou à l’amateurisme et de faire preuve d’une grande rigueur. Trop souvent, l’investissement est insuffisant et chacun reste avec sa propre vision du produit fini, sans la partager. Il faut poser toutes les questions délicates, car si elles ne trouvent pas de réponses claires et précises à ce stade, elles risquent fort de se transformer rapidement en situations délicates et en conflits.
La définition du scope en gestion de projet nécessite du temps, et donc de l’argent. Mais tout le temps passé lors de cette phase d’analyse ne sera pas perdu par la suite. Une fonctionnalité clairement définie, cadrée, sera réalisée plus facilement, avec moins de chances de débordement et d’insatisfaction du client au final.
Définir le plus précisément possible le périmètre d’un projet
Une fois la liste la plus exhaustive possible des fonctionnalités demandées établie, il faut encore déterminer quels seront les impacts sur les systèmes d’informations internes ou externes existants. En effet, le développement d’une nouvelle fonctionnalité peut très bien être lié à un système externe à l’application. Il est par exemple courant que le système d’identification des utilisateurs s’appuie sur un système existant, commun à d’autres applications. Il faudra donc prendre en compte les spécificités de ce ou ces services externes.
Par exemple, si l’identification d’un utilisateur se fait via un annuaire LDAP, il faudra prévoir les outils pour dialoguer avec lui. Si c’est un annuaire Active Directory, qui utilise une autre technologie et un autre format, il faudra prévoir d’autres outils. Ces outils peuvent exister ou devoir être créés de toutes pièces. Quoi qu’il en soit, il faudra les prévoir.
La prise en compte d’une fonctionnalité particulière conduit donc souvent à gérer ses dépendances. Les dépendances sont autant de tâches devant aboutir avant que la fonctionnalité concernée ne puisse être totalement terminée. Il faut les intégrer au périmètre du projet, au même titre que toutes les autres fonctionnalités.
Diviser le périmètre d’un projet en lots
Afin de mieux cerner le périmètre d’un projet, il peut être intéressant de définir différents modules et d’effectuer un lotissement. Lors du recensement des fonctionnalités, il est possible de faire émerger quelques grands domaines plus ou moins indépendants les uns des autres. Cela va permettre de regrouper certaines fonctionnalités dans des modules.
Par exemple, toutes les fonctionnalités liées à l’identification d’un utilisateur et à la gestion de ses droits peuvent être regroupées dans un module. Tout ce qui concerne la gestion des commandes ou des clients peut être regroupé dans un autre. Il faut ensuite déterminer les modules interdépendants, et ceux qui ne le sont pas.
Une fois les modules définis et les dépendances déterminées, le lotissement peut commencer. Le lotissement va consister à regrouper les modules dont les interdépendances sont les plus fortes. De cette façon, nous serons sûrs de retrouver dans un même lot tous les modules dépendants les uns des autres et de ne pas risquer d’en oublier.
Il est alors possible de considérer chaque lot comme un sous-projet, ayant son propre périmètre. La réalisation de plusieurs lots peut parfois être parallélisée, entièrement ou partiellement, en fonction des circonstances et des contraintes techniques.
Peut-on réellement figer le périmètre d’un projet ?
Le monde change, et le projet peut donc être amené à changer également. Est-ce vraiment utile alors de définir précisément le périmètre d’un projet ?
La réponse est évidemment oui. Il peut être déterminé précisément, sans pour autant être figé. Le scope du projet peut être amené à évoluer. Des fonctionnalités peuvent disparaître (ce qui est plutôt rare), et d’autres apparaître (ce qui est déjà plus courant), parce qu’un projet peut s’étaler sur plusieurs mois, voire plusieurs années pour les gros projets, et que les besoins du client, mais aussi les normes, les technologies et les outils, peuvent évoluer. La modification du scope peut également provenir de la nécessité de fournir un contournement face à un problème imprévu, qui malgré tous les efforts fournis en amont, n’a pas pu être anticipé, ou bien encore de la mise en place d’une meilleure méthode pour la mise en place d’une fonctionnalité.
Il est donc important de pouvoir faire évoluer le périmètre du projet afin de s’adapter aux changements. Pour cela, il faut mettre en place des procédures de gestion de ces évolutions. Cette procédure de gestion du changement doit être mise en place dès l’initialisation du projet et doit définir de manière précise la façon dont les différentes solutions doivent être prises en compte.
L’extension du périmètre initial du projet doit être fait en considérant trois facteurs :
- le respect des coûts,
- le respect de la qualité,
- et enfin, le respect des délais.
On peut considérer qu’une évolution du périmètre du projet est acceptable à partir du moment où elle n’entraîne ni la modification des jalons initiaux définis, ni un dépassement de budget significatif. Chaque modification doit être validée par le comité de pilotage du projet.
Si une modification lourde en termes d’impact est demandée par le client, elle peut alors être qualifiée d’évolution et doit dans ce cas faire l’objet d’un financement particulier venant s’ajouter à l’enveloppe initiale, et tout décalage des jalons doit être validé.
Un logiciel de gestion de projet efficace peut faire la différence. Testez gratuitement Nutcache et ses outils d’aide à la gestion du scope gestion de projet.
