Comment gérer un projet informatique ?

Un projet complexe par définition

Un projet informatique, qu'il s'agisse du développement d'un nouveau logiciel ou de l'installation d'une solution système d'information, tel un progiciel intégré de type ERP ou une gestion de la relation client de type CRM, sera complexe par définition.

Les multiples parties prenantes défendent des intérêts qui ne sont pas nécessairement congruents, l'équipe de développement nouvellement constituée n'a pas l'habitude de travailler en synergie et les technologies utilisées sont nécessairement encore un peu vertes, technologie informatique oblige. Bref, ce n'est pas simple.

On commence par oublier la hiérarchie des cellules de pilotage...

Le déroulement classique d'un projet d'envergure s'appuie sur un pilotage bicéphale, MOA-MOE, hérité de l'univers de la construction et des travaux publics. La MOE, Maîtrise d'Oeuvre, est chargée de la réalisation proprement dite et la MOA, Maîtrise d'Ouvrage, est orientée sur les aspects fonctionnels, la formalisation du besoin et le suivi au cours du déroulement de l'adéquation en le réalisé et le désiré. On en parle ici : A quoi peut bien servir un directeur de projet ?

Deux hypothèses erronées

Cette organisation, simple pour l'esprit, est malheureusement fondée sur deux hypothèses totalement erronées.

Hypothèse erronée 1

Les besoins sont clairement exprimés, et toutes les parties prenantes, que ce soient les donneurs d'ordre, les développeurs ou les utilisateurs, ont parfaitement compris de quoi il en retournait.

Mission impossible. Même dans le monde de la construction, il n'est pas toujours possible d'être suffisamment clair et exhaustif à la fois pour exprimer tous les non-dits, et formaliser une vision collégiale de ce qui doit être réalisé(1).

Chacun vit dans son propre système de références et perçoit à sa manière le besoin et la manière de l'accomplir. D'autres part, il n'est pas du tout évident que tous les donneurs d'ordre aient parfaitement compris dans les détails et en synthèse l'ampleur et la portée du projet...
Deux exemples pour illustrer ce propos :

• On se souviendra longtemps de projets ERP comme autant d'échecs "historiques", où les responsables "côté clients" cherchaient à contourner les processus imposés par le système pour appliquer leurs propres méthodes et règles de gestion.

  Ils n'hésitaient pas à se lancer tête baissée dans des développements sans queue ni tête en utilisant le langage propriétaire. Bref, l'usine à gaz, ses dysfonctionnement et les dépassements budgétaires étaient au rendez-vous (2).

• De même, tous les clients de projets CRM n'ont pas nécessairement bien compris la portée du concept (3). Plutôt que de développer en réseau la connaissance du client au sein de l'entreprise et de ses partenaires les plus proches, ce qui est la "vraie" finalité de l'outil, ils se contentent généralement de développer l'aspect automatisation des forces de ventes. Chacun pourra ajouter ses propres expériences à cette brève liste pour illustrer ce propos...

Hypothèse erronée 2

Les besoins n'évolueront pas au cours du déroulement du projet.
Nul besoin de longues démonstrations, il suffit d'avoir un jour assisté ou participé à un projet informatique d'une certaine ampleur pour constater que l'on ne pourra se contenter d'un principe d'avenants à répétition pour préciser ou corriger les exigences initiales.

Au fur et à mesure de l'avancement du projet, si les réunions sont correctement conduites, la compréhension du besoin évolue sensiblement. De même, les donneurs d'ordre comprennent mieux les spécificités techniques, et découvrent de nouveaux services potentiels tout à fait réalisables avec la technologie mise en oeuvre...

Quelques compléments...

• (1) Les dépassements de budget ne sont pas une exclusivité des projets informatiques, voir notamment les multiples déboires de l'architecte Santiago Calatrava et Devis bidons et l'explosion des coûts finaux)
• (2) A leur décharge, il faut aussi reconnaître que les systèmes propriétaires étaient bien peu flexibles et n'autorisaient qu'une personnalisation bien limitée. Cette rigidité quasi incontournable explique aussi les échecs des projets ERP. Depuis, il est vrai, le contexte a évolué et les éditeurs sont tenus de réviser leur offre... Voir à ce sujet le dossier ERP Progiciels intégrés, le chapitre "Tendances".
• (3) Remarque personnelle : je me suis toujours heurté à un certain hermétisme des managers fonctionnels qui rechignent à s'impliquer un peu plus avant au coeur des projets technologiques. C'est à leur attention que j'avais bâti le "digest" "Le bon usage des technologies expliqué au manager" publié aux éditions Eyrolles en 2001.

  L'objectif était qu'ils soient suffisamment armés pour "résister" aux discours des vendeurs et consultants, et puissent mieux intégrer les technologiques en parfait accord avec la stratégie engagée. L'alignement stratégique était un thème central durant les années 90. Il le fut encore dans les années 2000. Il le sera toujours en 2012, 2013, 2014...

Lire la suite : Manager le projet

Ces bonnes pratiques sont détaillées, expliquées, mises en perspective et illustrées dans l'ouvrage de référence du site :

Livre de référence

Le chef de projet efficace 12 bonnes pratiques pour une démarche d'entrepreneur Alain Fernandez Eyrolles 4ème édition 2011 - 220 pages Prix librairie : 19 Euros

Dispo chez : eyrolles.com fnac.com amazon.fr

Page suivante Les méthodes

Commentaires lecteurs...

Pour aller plus avant ...

Phases du projet Définition projet WBS Work Breakdown Structure Planification et diagramme de Gantt

PMBOK Project Management Body PMI Méthode Prince 2 Méthodes agiles, le dossier Estimer les délais

Partagez cet article...

---

Copyright : Alain FERNANDEZ ©1998-2013- Tous droits réservés
Toutes les marques citées sur cette page sont des marques déposées de leurs propriétaires respectifs

---