Les nombreux projets que nous avons été amenés à réaliser nous ont permis de mieux comprendre que la gestion des exigences est fortement dépendante des contextes et des environnements de réalisation.
Plus généralement, la typologie du projet, la nature des produits et des solutions déployées, les enjeux et les attendus du client et autres facteurs auront une incidence directe sur les modalités de compréhension, de maîtrise et de suivi des exigences.

Nos vécus de chefs de projet dans le domaine des télécoms empruntent aussi bien aux grands projets de type R&D basés sur le développement de « releases » radio majeures dite « BSS » (La BSS est l’ensemble des éléments radio du réseau GSM situés autour de l’antenne BTS (« Base Transceiver Station ») qu’à des projets plus petits de déploiement rapide de solutions de prépayé, postpayé et de facturation « IN-VAS et billing » (« IN »: Intelligent Network, « VAS » : Value Added Services).

En termes de business, au niveau des projets R&D, le modèle alors appliqué auprès des clients opérateurs de téléphonie était celui d’une « release », composée de ses divers sous-systèmes radio, et renouvelée environ tous les deux ans avec des « roadmaps » largement communiquées et partagées avec les clients. Ainsi, une fois les discussions réalisées avec l’ensemble des programmes déployés et les clients opérateurs, la direction technique procédait avec les responsables des sous-systèmes R&D à un arbitrage permettant d’identifier et de figer les fonctionnalités associées à la release générale. Une seule et même release radio était alors proposée aux clients avec, dans quelques cas seulement, d’éventuels ajouts de fonctionnalités relativement au besoin de l’opérateur. A titre d’exemple, nous avons piloté la conception et le déploiement du sous-système d’optimisation de réseau RNO (version 3), pour « Radio Network Optimisation », utilisé par une bonne centaine d’opérateurs télécoms à travers le monde. Au cours de ces projets R&D, qui s’étalaient généralement sur une année et demie voire deux années, les exigences et fonctionnalités associées faisaient l’objet de discussions dès l’amont et d’une stabilité généralement peu remise en cause par la suite. Leur compréhension par les équipes, le client et autres parties prenantes du projet en était rendue plus aisée.

Ce business model et cette approche quelque peu monolithique tranchait fortement avec celle des programmes de déploiement de la solution « IN-VAS et billing » que nous avons menés, et dont les services, à la différence des infrastructures de la BSS, avait un caractère discriminant porté par une forte valeur ajoutée. La nécessité de pouvoir déployer rapidement les  solutions « IN-VAS et billing » coïncidait avec le rôle clé joué par les services IN et VAS en matière de « discriminant marketing » pour les opérateurs dont toute la communication et les plans marketing, lancés en avance de phase, annonçaient la mise à disposition prochaine de ces services pour leurs futurs abonnés. Il s’agit d’un aspect d’autant plus important qu’une préoccupation majeure des opérateurs de téléphonique mobile, et tout particulièrement avec l’aide des solutions « IN-VAS et billing », est d’offrir des fonctionnalités toujours plus innovantes, utiles à la captation de nouveaux abonnés, mais plus encore, à la conservation de leurs propres abonnés, limitant ainsi le taux d’attrition (Le taux d’attrition (ou churn , de l’anglais to churn up, brasser, agiter) exprime le taux de déperdition affectant la base clients d’ une entreprise ou un produit. Ce taux mesure le pourcentage de clients perdus, sur une période donnée (en général une année) par rapport au nombre total de clients existants au début de cette période).

Plus largement, le déploiement d’un réseau de télécommunications représentait un enjeu d’importance dans l’idée d’apporter et de mettre à disposition les services de téléphonie mobile à toutes les franges de la population, y compris les plus pauvres.

Cela donnait lieu, et selon les attendus client, sur la base des releases génériques des produits, à des développements  spécifiques engendrant le plus souvent une divergence avec la release générique d’origine.  Il s’agissait des activités nommées « Customer Design Engineering » (CDE).  En tant que chefs de projet nous avons organisé des rencontres avec d’autres chefs de projet de l’unité d’affaire afin de mieux cerner les avantages et les désavantages d’une telle approche ; Nous comprenions mieux au travers des discussions et des précédents déploiements, ce fort coté discriminant des  « services » et dans le même temps avions entrevu, les risques de divergence et des régressions que pouvaient engendrer ces développements spécifiques réalisés au cours des programmes.

Un autre constat, au travers de cette spécialisation des développements à partir des solutions R&D, outre la divergence des solutions déployées d’un client à l’autre, d’un projet à l’autre, se situait au niveau de la difficulté pour les chefs de projet de reboucler avec les équipes R&D en charge des releases génériques, afin de capitaliser sur les développement réalisés.

Au final, nos équipes projet avaient souvent, dans la gestion des exigences, très proches des attendus spécifiques de leur client, une difficulté à se faire aider efficacement par les équipes R&D, les développements réalisés ayant souvent divergé avec ceux de la release générique.

Ainsi, dans ce type d’environnement et de typologie de projet, pour les chefs de projet et son équipe, la maîtrise des exigences et la mise en place d’une solide gestion de configuration devenaient encore davantage des incontournables, nécessitant une attention portée du chef de projet de tous les instants.

Par ailleurs et dans le cadre de nos projets à fortes spécificités clients, nous avons été amenés à mettre en place des indicateurs clés pour suivre la cohérence et l’implémentation des exigences. En particulier, deux métriques ont été utilisées : la mesure de cohérence et la vélocité.

La première vise à assurer la cohérence des exigences avec les attendus des parties prenantes. Pour cela, il est nécessaire d’employer les techniques appropriées pour clarifier et analyser les exigences avec les différentes parties du projet et éviter les contradictions entre exigences. Parmi ces techniques, on peut citer par exemple : la modélisation au travers de cas d’utilisation, les diagrammes de flux de données, les diagrammes d’état, le prototypage ; etc. …

La cohérence peut se mesurer au travers du ratio entre les exigences inclues, exigences exclues, exigences en évaluation et exigences litigieuses sur le nombre total des exigences.

La vélocité est une mesure permettant de calculer la vitesse de progression du projet.

En mode itératif incrémental, la vélocité traduit le nombre de fonctions qu’une équipe peut réaliser par itération.

Cette mesure a pour origine SCRUM qui est une méthode de développement logiciel en mode AGILE. Elle est utilisée pour détecter un problème de qualité. En effet, le ralentissement de la vélocité traduit généralement le manque d’évolutivité du produit logiciel ou l’apparition de nombreux bugs.

Dans notre prochain article, nos experts en formation management de projet aborderont la maîtrise des exigences, les clés de lectures et les clés de succès.