Gestion des exigences : une des clés du succès des projets in­for­ma­tiques

Une fois le budget fixé, l’objectif décrit et le délai défini, les en­tre­prises se dépêchent souvent de passer di­rec­te­ment à la mise en œuvre au lieu de prendre un peu de temps pour ras­sem­bler de façon sys­té­ma­tique les exigences de toutes les parties prenantes pour le produit souhaité et en gérer les spé­ci­fi­ca­tions. Problème : les exigences définies ini­tia­le­ment sont uni­que­ment intégrées au produit final dans 56 pour cent des projets in­for­ma­tiques. Il en découle une perte de temps et de budget qui peut être évitée avec une gestion des exigences struc­tu­rée.

La gestion des exigences, également appelée Re­qui­re­ments En­gi­nee­ring ou Re­qui­re­ments Ma­na­ge­ment, est une com­po­sante fon­da­men­tale de la gestion de projet dans les en­tre­prises. L’objectif est de veiller à sa­tis­faire les exigences des clients, mais aussi des parties prenantes internes et externes pour le produit à élaborer.

Cette dis­ci­pline inclut la dé­fi­ni­tion des exigences (l’analyse, la do­cu­men­ta­tion et la va­li­da­tion des exigences) ainsi que la gestion des exigences (gestion des risques, des mo­di­fi­ca­tions et de la mise en œuvre). Il ne s’agit donc pas d’une tâche unique que l’on réa­li­se­rait au début d’un projet, mais bien d’une suite de processus ré­cur­rents qui s’étendent sur toute la durée du projet. Le chef de projet res­pon­sable, appelé ingénieur de gestion des exigences ou en anglais Re­qui­re­ments Engineer, surveille la mise en œuvre et l’in­té­gra­tion des exigences et des mo­di­fi­ca­tions ainsi que le cours du projet qui en découle.

La gestion des exigences in­for­ma­tiques est re­la­ti­ve­ment bien établie dans le secteur des tech­no­lo­gies. Au niveau des projets in­for­ma­tiques, si l’on ne définit pas clai­re­ment d’entrée de jeu ce que le logiciel à dé­ve­lop­per doit être en mesure de réaliser et quels processus il doit supporter, on peut s’attendre à des problèmes dans la suite du processus. Toute pla­ni­fi­ca­tion du temps et des res­sources effectuée sur cette base ne saurait être réaliste et il y a alors fort à parier que le projet s’éter­ni­sera et que le budget sera dépassé du fait des diverses mo­di­fi­ca­tions sou­hai­tées par le client. En effet, une mauvaise gestion des mo­di­fi­ca­tions sou­hai­tées entraîne davantage de dépenses.

La gestion des exigences est toutefois utile et es­sen­tielle, quel que soit le secteur. Dans les projets d’envergure portant en par­ti­cu­lier sur des produits complexes, elle permet de maintenir l’ef­fi­ca­cité à un niveau élevé tout au long du projet et d’éviter les erreurs et les dé­sac­cords entre les par­te­naires du projet. Les problèmes provenant d’un chan­ge­ment dans les souhaits du client peuvent être gérés de façon anticipée par un ingénieur de gestion des exigences qui définira des mesures afin d’en atténuer les effets négatifs.

Même si au départ, le client doit consacrer des efforts plus im­por­tants pour spécifier plus en détail les exigences, une gestion des exigences struc­tu­rée favorise la sa­tis­fac­tion client.

L’im­por­tance de la dé­fi­ni­tion et de la gestion des exigences dans la réussite du projet a pourtant tendance à être sous-estimée par les en­tre­prises – même dans les projets tech­no­lo­giques où la gestion des exigences in­for­ma­tiques est largement répandue. C’est en tout cas ce que laisse supposer l’étude CHAOS du cabinet de conseil Standish Group qui indique que 52 pour cent des projets in­for­ma­tiques dépassent de loin les délais et le budget . Seulement 55 pour cent des personnes in­ter­ro­gées con­si­dé­re­raient la gestion des exigences comme im­por­tante ou très im­por­tante. Pour les autres par­ti­ci­pants, la gestion des exigences par­ti­ci­pe­rait uni­que­ment fai­ble­ment ou moyen­ne­ment à la réussite du projet. Une grave erreur comme le montre le nombre de projets livrés en temps et en heure.

• une plus grande ef­fi­ca­cité du projet
• moins de mo­di­fi­ca­tions au cours du projet
• moins d’erreurs et de dé­sac­cords
• une iden­ti­fi­ca­tion précoce des problèmes et des mo­di­fi­ca­tions né­ces­saires
• des coûts de projet plus faibles, les coûts dus aux erreurs pouvant être évités
• un projet achevé dans les temps et en res­pec­tant le budget
• une plus grande sa­tis­fac­tion client

Parmi les prin­ci­pales tâches de la gestion des exigences, on trouve la collecte, la do­cu­men­ta­tion et l’analyse des exigences ainsi que la gestion des mo­di­fi­ca­tions au cours du projet.

Les exigences des dif­fé­rentes parties prenantes doivent tout d’abord être col­lec­tées. L’ingénieur de gestion des exigences dispose de dif­fé­rentes méthodes pour faire ressortir les besoins et les souhaits des parties prenantes et du client afin de créer une do­cu­men­ta­tion des exigences :

• des in­ter­views : l’ingénieur de gestion des exigences peut s’en­tre­te­nir avec les parties prenantes en personne ou par téléphone.
• des ques­tion­naires : il peut également in­ter­ro­ger les parties prenantes par écrit afin de re­cueil­lir les exigences sous une forme struc­tu­rée. Il est ainsi possible de re­cueil­lir les exigences d’un grand nombre de parties prenantes.
• des ateliers : à l’aide de tech­niques créatives, les parties prenantes peuvent être guidées à travers des ateliers afin de découvrir des aspects à prendre en compte dans le projet auxquels ils n’auraient pas pensé lors d’un simple brains­tor­ming.
• des ob­ser­va­tions sur le terrain : l’ingénieur de gestion des exigences observe les processus de travail des parties prenantes et les documente à l’écrit, au format audio ou sous forme de vidéo.
• l’ap­pren­tis­sage : l’ingénieur de gestion des exigences apprend l’activité de la partie prenante. Grâce aux ex­pli­ca­tions apportées sur le travail de cette dernière, il prend alors cons­cience d’exigences im­por­tantes pour le projet.
• des re­cherches sur un système : pour les in­fras­truc­tures in­for­ma­tiques peu ou pas do­cu­men­tées, l’ingénieur de gestion des exigences peut commencer par l’examen et la do­cu­men­ta­tion du système. Dans ce cadre, son analyse per­son­nelle peut être complétée par des ques­tion­naires remplis par les uti­li­sa­teurs des systèmes.
• une réu­ti­li­sa­tion : si un système technique doit être renouvelé, il est probable qu’il faille conserver les workflows auxquels les uti­li­sa­teurs se sont habitués. Au lieu de re­for­mu­ler toutes les exigences, il convient de s’appuyer sur les do­cu­men­ta­tions exis­tantes.

Le cahier des charges sert de base con­trac­tuelle entre les par­te­naires du projet. Il s’agit du premier produit créé dans le cadre de la gestion des exigences. Il rassemble l’ensemble des exigences du donneur d’ordre con­cer­nant la pres­ta­tion et la livraison de l’exécutant. Il définit ce qui doit être réalisé. Il est ensuite possible de définir la mise en œuvre dans un cahier des charges fonc­tion­nel.

Dans de nombreux cas, il peut être pertinent de ne pas consigner uni­que­ment les exigences par écrit, mais aussi sous forme graphique, en par­ti­cu­lier lorsqu’il est né­ces­saire de décrire des systèmes, des processus et des cas d’uti­li­sa­tion. Pour ce faire, on utilise gé­né­ra­le­ment des dia­grammes UML.

Après le re­cen­se­ment et la collecte des exigences, l’ingénieur de gestion des exigences doit les analyser. Les exigences con­tra­dic­toires doivent être iden­ti­fiées et cla­ri­fiées avec les parties prenantes. Par ailleurs, l’ingénieur doit recenser et évaluer les risques (éva­lua­tion selon l’ampleur po­ten­tielle des dommages et le degré de pro­ba­bi­lité). Un clas­se­ment des exigences par ordre de priorité doit également être effectué.

Il s’agit ensuite de présenter la do­cu­men­ta­tion des exigences aux parties prenantes pour vé­ri­fi­ca­tion. La mise en œuvre du projet ne pourra commencer que lorsque l’ensemble des parties prenantes se seront accordé sur un cahier des charges.

La (quasi) totalité des projets inclut des mo­di­fi­ca­tions en cours de projet. Afin de réduire à un minimum les dis­cus­sions sur les efforts sup­plé­men­taires né­ces­saires et, en cas d’in­sa­tis­fac­tion du client, de pouvoir revenir à une version an­té­rieure du projet, l’uti­li­sa­tion de versions s’est révélée utile. Issue du dé­ve­lop­pe­ment logiciel, cette méthode est également utilisée dans la gestion de projet. Elle consiste à do­cu­men­ter les versions du projet et à désigner les versions actuelles comme nouvelle base de travail. Il est ainsi possible de comparer fa­ci­le­ment les exigences anciennes et actuelles.

De nom­breuses en­tre­prises partent du principe qu’une gestion des exigences n’est pas né­ces­saire dans les projets agiles puisque les objectifs changent au fil du projet. C’est une erreur.

La majorité des tâches de la gestion des exigences sont reprises par le Product Owner dans les projets agiles. Il surveille et pilote le dé­rou­le­ment du projet ainsi que la mise en œuvre des exigences. Par ailleurs, il établit la priorité des exigences et assure la coor­di­na­tion des mo­di­fi­ca­tions. Ces tâches sont ty­pi­que­ment celles d’un ingénieur de gestion des exigences.

Lorsque le Product Owner n’est pas en mesure de gérer seul l’ensemble des tâches de la gestion des exigences, il est possible de nommer d’autres col­la­bo­ra­teurs qui veil­le­ront à la reprise des nouvelles exigences et tiendront à jour la do­cu­men­ta­tion, par exemple des mo­di­fi­ca­tions.

Bien que la gestion des exigences soit moins con­sé­quente dans les projets agiles, elle est tout aussi es­sen­tielle que dans les projets gérés de façon classique selon le modèle en cascade.