La prise en compte du risque

Les trois axes

Le chef de projet en devenir est parfois perplexe face au nombre des éléments qu’il doit organiser pour aboutir. Dans quelle direction partir ? Par quoi commencer et comment continuer ?

Pour répondre à ces questions, il faut d’abord se représenter le processus du projet tel que nous l’avons décrit au chapitre Démarrer un projet informatique. Cette fois-ci, nous choisissons un espace structuré par trois axes, le temps (cycle de vie), l’analyse et le pilotage.

Chaque dimension de cet espace correspond elle-même à une méthode plus ou moins standard, qui donnera lieu à un processus que le chef de projet devra suivre.

Le premier axe (en abscisse horizontale) est celui qui décrit les phases du projet, tel que l’on peut le préfigurer. Le schéma ci-dessus propose un modèle de développement assez standard, partant de l’expression des besoins, évoluant jusqu’à la livraison (production) et la maintenance du projet. En toute rigueur, on devrait introduire la mort du projet, car nous savons que le cadre support n’est pas infini. Nous le verrons par la suite, d’autres modèles de développement existent et proposent des organisations différentes.

Vient ensuite l’axe d’analyse (en ordonnée, vertical). Il indique le niveau d’abstraction...

Le modèle de développement

Le modèle de développement constitue l’un des premiers choix que doit effectuer le chef de projet. Il façonne de manière explicite l’organisation temporelle du projet et a une grande influence sur le résultat final.

Il n’y a pas de bon ou de mauvais modèle, du moins parmi les grandes classes dont l’énumération suit. Cependant, chaque projet a des caractéristiques qui rendent l’application d’un modèle judicieuse ou au contraire inefficace.

1. Le modèle cascade

On l’appelle aussi modèle linéaire ou modèle nominal. C’est certainement le modèle le plus simple, ce qui ne le déprécie pas pour autant !

Dans ce modèle, chaque étape suit la précédente, sans autre nécessité que « d’attendre » son issue ; dès que l’expression des besoins est terminée, les spécifications sont écrites. Au terme de ce travail, le développement est réalisé jusqu’à son achèvement. Les tests unitaires s’enchaînent, et ainsi de suite.

Avant d’expliquer l’appellation cascade, intéressons-nous aux différentes étapes prévues par ce modèle.

Idée - démarrage	C’est le point de départ du projet, le moment où les conditions matérielles sont remplies et où la vision du projet est partagée par l’équipe.
Expression des besoins	Après la décision d’enclencher un projet, on refait le tour des utilisateurs pour recueillir plus en détail leurs exigences fonctionnelles. Ces requêtes sont consignées dans un classeur (papier ou tableur), identifiées, et finalement regroupées ou recoupées.
Spécifications	L’ensemble des requêtes est considéré selon différentes approches dictées par le modèle d’analyse : importance, priorité, difficulté technique, risques… Il ressort des spécifications un découpage technico-fonctionnel de l’application.
Développement	Les spécifications sont traduites en code, en projetant le découpage modulaire (composants)...

Le modèle d’analyse

Ce modèle régit l’étude du système en devenir. La majorité des méthodes (modèles) commencent par dégager les contours de ce système pour éviter de se concentrer sur des détails externes. Ensuite, le système est étudié sous l’angle des stimuli utilisateurs puis formalisé. Évidemment, toute la difficulté de l’exercice réside dans l’absence d’une existence concrète dudit système.

Avant de décrire les grandes lignes des méthodes les plus utilisées, Merise et UML, nous allons découvrir comment procéder pour modéliser les systèmes informatiques.

1. Le principe de modélisation en analyse

La modélisation est une abstraction de la réalité. Le simple relevé d’une situation sur un document en constitue une abstraction. Quels sont les buts recherchés ? Il s’agit tout d’abord de décrire avec un minimum de formalisme le système cible. À ce titre, Merise parle de sous-ensemble représentatif (SER). Cette « simplification » est primordiale pour qui veut participer aux spécifications d’un projet sans avoir le produit final sous la main. La modélisation, c’est aussi une technique pour définir les priorités dans un projet. Certains détails figurant dans les artefacts utilisateurs n’ont aucun sens réel, alors que d’autres se révéleront de première importance.

Pour le chef de projet, la modélisation est un processus qui, rappelons-le, lui permettra de traiter au mieux son sujet en favorisant la réutilisation et la généricité. Voici comment procéder.

La modélisation s’effectue en trois étapes : l’abstraction, l’instanciation et la vérification.

L’abstraction est l’étape la plus délicate. Il s’agit d’analyser l’existant pour en dégager l’essentiel, sans introduire de biais. Le piège réservé habituellement aux programmeurs débutants réside dans l’introduction inappropriée de détails qui seront autant de biais et d’efforts...

Le modèle de pilotage

Nous connaissons la maxime « gouverner c’est prévoir » et nous pourrions nous demander si elle est applicable à la conduite de projet. C’est précisément l’objet du pilotage que de prévoir la survenue d’aléas et d’anticiper des changements critiques du processus de projet.

Là réside la différence principale entre l’association du développement et de l’analyse avec le pilotage. Les deux premiers modèles sont imbriqués et sont les constituants du processus de projet. Le pilotage contrôle le processus avec une vision extérieure, plus systémique ; le projet, en tant que processus, fait partie d’un ensemble de flux de travail qui caractérise l’activité de l’entreprise. Cette activité n’est pas seulement tournée vers l’intérieur, mais elle met en relation l’entreprise avec des partenaires, des clients, des fournisseurs et des sous-traitants.

Le pilotage d’un projet est ainsi une technique de contrôle du projet (un processus « local ») à échelle de l’entreprise ; ce qui signifie que le comité de pilotage implique une partie seulement de l’équipe projet (généralement le chef de projet), mais aussi des représentants du comité de direction de l’entreprise, ainsi que leurs homologues membres des organisations associées au projet (partenaires, clients).

Comme nombre d’activités traitées à ce niveau, la vision ne se base pas sur le détail, mais plutôt sur des agrégats d’informations élémentaires que l’on appelle indicateurs clés de performance (Key Performance Indicator ou KPI). Grâce à ces indicateurs, le comité de pilotage donne de nouvelles orientations et modifie les priorités.

Le risque est évalué en permanence et ce sera en dernier ressort au comité de pilotage de décider de l’issue du projet, en cas d’aggravation sensible du niveau de risque ou de l’avènement d’aléas aux conséquences néfastes.

La prise en compte du contexte métier et des processus...

Prendre en compte le risque

1. L’analyse des risques

Combien de projets a-t-on vus abandonnés en cours de route, ou même à leur livraison ? Beaucoup trop, c’est certain. L’informatique a parfois mauvaise réputation - trop complexe, peu fiable, coûteuse. Les équipes projets aussi - trop lentes, trop frileuses, incapables de s’adapter à de nouvelles technologies. N’évoquons pas non plus le sujet des langages de programmation - objet, pas objet, trop récents, obsolètes. Et puis les projets sont critiqués dans leurs caractéristiques les plus fondamentales - trop gros, pas assez dotés, pas assez rentables pour se permettre d’investir, etc.

Les critiques fusent de toutes parts, avant, pendant, et même après. S’il n’est jamais agréable d’être visé par ces récriminations, même si certaines d’entre elles sont fondées, c’est plutôt la forme qui passe mal ! L’analyse des risques est une activité cruciale de la conduite de projet. Elle a pour but de « consommer » toutes les remarques, alertes, critiques, objections soulevées avant et pendant le projet, pour mener les opérations à leur terme dans les meilleures conditions de prévision qui soient.

a. Les classes de risques

On s’intéresse toujours aux mêmes thématiques. Des questions apparemment opposées couvrent en réalité un même type de risque. Prenons le cas du langage de programmation. Pour untel, il est inenvisageable de développer de nos jours sans un langage qui ne réponde aux paradigmes objets. Pour tel autre, au contraire, l’introduction d’objets dans un script est source de complexité, voire de complications inutiles. Qui a raison ? Tout dépend des circonstances. On ne pourrait pas établir un classement des meilleures technologies. Chacune d’elles est prévue pour un certain cadre d’applications, où elle donnera d’excellents résultats. Dans un cadre différent, elle peut tout aussi bien nuire à la réalisation du projet.

Autrement dit, nous n’allons pas établir une liste des risques, mais plutôt de types de risques. À charge pour...

Étude du risque pour le projet de CRM

La Société de Conseil Plus a mandaté Guillaume, informaticien, pour assister la responsable marketing qui se trouve être également la chef de projet, Annie. À deux, ils recensent des risques applicables à leur projet de mise en œuvre d’un CRM. Le produit de leur réflexion aura un double impact. Tout d’abord, le niveau de risque sera actualisé à chaque comité de pilotage, de façon à anticiper des périodes clés pendant lesquelles une attention doit être portée sur des aspects particuliers du projet. D’autre part, l’évaluation du profil de risque va guider le choix d’un fournisseur et prestataire venant déployer la solution suivant une méthodologie adaptée.

1. Analyse des risques

a. La faisabilité du projet

Ce n’est pas faire injure aux commanditaires (sponsors) que de s’assurer de la compatibilité du cadre du projet aux objectifs stratégiques. Autrement dit, on se pose la question de la durée du projet et de la date de lancement opérationnel (go live), ainsi que de la dotation budgétaire.

Le projet démarre au mois d’octobre, prévoit deux mois de sélection d’un fournisseur et six mois de mise en œuvre. Le go live tomberait donc en début de période estivale de l’année suivante, dans le meilleur des cas. Ce moment n’est sans doute pas propice au lancement d’une nouvelle application, car la plupart des utilisateurs prendront leurs congés. Guillaume suggère à Annie de tirer malgré tout parti de cette période pour effectuer un lancement « en douceur » (soft opening) avec des effectifs réduits et des associés un peu plus disponibles autour de leurs congés. Annie considère avec intérêt cette idée mais redoute par ailleurs que les prestataires ne soient pas réellement disponibles dès après la conclusion du contrat. Elle s’attend de plus à ce que les négociations durent plus longtemps qu’escompté par la DAF.

Annie a sans doute raison car l’absence d’identification d’un budget précis ne mettra pas la société dans...