Chaine youtube Piloter.org   Piloter.org sur facebook   Profil  Linkedin   Actualités Twitter
Plus de 800 fiches pratiques pour les managers, sans pub et sans traceurs…
Le Portail du Manager Innovant
Chaine youtube Piloter.org Je suis aussi  sur facebook  Je suis aussi sur  Linkedin  Actualités Twitter
×
★ Tous les articles classés ★

Le projet informatique, un projet complexe par définition

Conduire un projet informatique d'entreprise n'est pas une partie de campagne. Loin s'en faut. Il s'agit en effet de construire une équipe aux compétences pointues pour mettre en oeuvre des technologiques jeunes, et donc délicates, au service de parties prenantes qui ne sont pas toujours d'accord sur les enjeux de projet. Voyons tous cela.

Les quatre types de conduite de projet

Types de conduite de projet
Légende : Ce schéma est extrait du livre les nouveaux tableaux de bord des managers, et expose l'intérêt d'associer l'usage d'une méthode adaptée et un principe de communication et d'échanges continus entre toutes les parties prenantes du projet.

Comment conduire le projet informatique ?

Avec une communication permanente, comme le temps 4 ici entouré ! C'est bien le seul moyen de faire "à peu près" coller le projet réalisé avec les attentes des donneurs d'ordre.

Seulement, et oui, il y a un "seulement", ça ne se passe pas toujours ainsi. C'est bien connu, nul besoin de faire un dessin. Alors reprenons dans l'ordre tout ce qu'il faut abandonner, oublier, enterrer de la conduite des projets classique.

Pour bien gérer le projet informatique, on oublie les démarches classiques...

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.

Ensuite, on oublie 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é.

Gestion de projet informatique

Ce modèle est fondé sur 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 ? Quelle illusion !

Théorie 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'autre 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...

Quelques précisions...

  • (1) Les dépassements de budget

    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) La rigidité des solutions

    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) L'hermétisme des fonctionnels

    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.
  • (4) L'alignement stratégique

    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 demain...

Hypothèse erronée 2 : Les besoins n'évolueront pas... Ah bon ?

Théorie 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...

On coopère, on mesure, on anticipe et on accompagne !

On coopère...

Un projet technologique est un projet complexe par définition. Il n'est pas très judicieux d'adopter un mode de management directif pour le mener à son terme. Il est très nettement préférable d'adopter un mode de gestion du projet plutôt coopératif.
C'est d'ailleurs là le principe fondamentale de la méthode Gimsi utilisée pour la conduite du projet Business Intelligence.
Il est aussi utile d'étudier de près les méthodes agiles, elles sont fondées sur un principe de coopération et d'échanges continus. C'est là leur dynamique.

Manager par la valeur estimée

Mais il n'est pas non plus recommandé de s'imaginer vivre dans un monde merveilleux. Parmi les parties prenantes, il n'y a pas que des copains. Pour être un peu plus concret, chacun essaie de tirer au mieux son épingle du jeu.
Il est donc prudent de suivre les enjeux en termes de valeurs au sens de chacune des parties prenantes.

On mesure...

On évitera de se laisser enfermer dans la spirale du reporting ou du "rendre compte à tout instant" pour bâtir un vrai tableau de bord de pilotage qui permettra à l'équipe de mieux s'organiser, d'anticiper les coups de colliers et de livrer un produit conforme aux exigences, quelles qu'elles soient (stratégiques, techniques, performances, ergonomiques...).
En complément : on oublie un peu le rigorisme de la planification et de l'ordonnancement, et on n'hésitera pas à mettre un peu de mou dans les Gantt et Pert que l'on compensera par un effort de dynamisation du relationnel entre les membres de l'équipe et ses partenaires, tout en développant un esprit qualité (voir notamment Ce que sait la main, un essai sur la qualité de Richard Sennett)...

...on anticipe...

La gestion des risques du projet n'est pas une formalité. Il est tout de même aberrant de négliger cette étape, et de se retrouver en plein coeur du projet aux prises avec un sinistre parfaitement prévisible...

...et on accompagne !

Et on accompagne la mise en oeuvre du projet de bout en bout, sans omettre d'intégrer les coûts de la conduite du changement dans l'enveloppe budgétaire initiale...Ces bonnes pratiques sont détaillées, expliquées, mises en perspective et illustrées dans l'ouvrage de référence du site : Le chef de projet efficace.

Quelle méthode pour votre projet informatique ?

Reprenons dans l'ordre les différentes phases.

Les besoins sont-ils bien exprimés ?

C'est bien là la principale source de problèmes des projets informatiques. Les méthodes agiles bouleversent les approches traditionnelles de conduite de projets de développement informatique pratiquées jusqu'alors. Les méthodes classiques conditionnent la réussite du projet à la qualité de l'expression des spécifications initiales.
Toute la réalisation et, notamment, l'élaboration du plan (délais, ressources, budget, qualité) seront conduites en référence aux besoins exhaustivement exprimés.

Inverser l'ordre des choses

C'est une démarche projet à "flux poussé". Nous sommes dans le domaine du déterminisme prédictif de type Laplacien. Si le projet est correctement conduit, il devra coller pile-poil aux spécifications initiales. Tout est prévu. Ce postulat régit toute la réalisation.

La conception dépend de la précision et de la stabilité des spécifications. C'est à ce point précis que commence la remise en question. Les référentiels de conduite de projet s'inscrivent d'ailleurs dans cette logique déterministe.

Que faire lorsque les spécifications changent ?

En effet, imaginons que les spécifications évoluent en cours de réalisation. Lorsque l'on reste dans les limites du raisonnable, il suffit de faire un avenant. Pour le moment, ce n'est pas encore bien compliqué.

Considérons maintenant le cas où les spécifications s'avèrent incomplètes non pas par négligence, mais bien parce qu'il est de nature impossible d'envisager toutes les situations au préalable. C'est le cas pour la majorité des projets informatiques un peu conséquents. En cours de réalisation, le client va peut-être découvrir de nouvelles possibilités, de nouvelles orientations bien plus intéressantes, nettement plus économiques ou profitables.

Faudra-t-il faire "beaucoup" d'avenants ? Ça n'est pas une solution viable sauf pour bâtir des usines à gaz.

Dans ce cas d'ailleurs, le prestataire professionnel se réfère à juste titre aux spécifications initiales. Elles sont contractuelles. Le client n'avait qu'à prévoir. D'où l'intérêt de n'engager que des projets très courts au périmètre bien délimité. D'où aussi l'intérêt des méthodes agiles qui proposent de prendre le problème par l'autre bout et d'adopter une démarche adaptative en lieu et place de la démarche prédictive.

Tuto: Les compétences du chef de projet efficace

Cette formation se déroule en quatre chapitres : -

Voir ici toutes les vidéos de formation pour devenir un chef de projet efficace, c'est-à-dire celui qui a bien compris la dimension humaine (accord, conflit, intérêt...) d'un projet d'entreprise.

Formations en ligne pour devenir un chef de projet efficace

L’auteur

Alain FernandezAlain Fernandez est un spécialiste de la mesure de la performance et de l’aide à la décision. Au fil de ces vingt dernières années, il a conduit et accompagné de nombreux projets d'entreprise en France et à l'International. Il est l'auteur de plusieurs livres publiés aux Éditions Eyrolles consacrés à ce thème et connexes, vendus à plusieurs dizaines de milliers d'exemplaires et régulièrement réédités.
Me suivre sur LinkedIn

Voir aussi... À ce sujet, voir aussi

  • Scrum, la méthode agile
    La méthode Scrum est une méthode agile de gestion de projets informatiques privilégiant la communication et facilitant les réorientations opportunes.C'est désormais la méthode privilégiée pour les démarches dites agiles.
  • Définition et principe des méthodes agiles
    Les méthodes agiles caractérisent un mode de gestion des projets informatiques qui privilégie le dialogue entre toutes les parties prenantes. Il s'agit de rompre avec les pratiques plus traditionnelles bien trop rigides et trop exigeantes en matière de spécifications (contractuelles).
  • RAD (Rapid Application Development)
    La méthode RAD, Rapid Application Development, est l'une des toutes premières méthodes agiles formalisée en 1991 par James Martin.


A lire À lire...

Pour réussir les projets d'entreprise, adoptez une démarche qui dynamise le relationnel entre les femmes et les hommes. Livre de référence du site…

Le chef de projet efficace
12 bonnes pratiques pour un management humain

Alain Fernandez
Eyrolles 6ème édition
248 pages

Consultez la fiche du livre »»»

Pour acheter ce livre :

Amazon.fr  Eyrolles.com  Fnac.com

Format ebook : PDF & ePub, Kindle


Un guide de référence des méthodes agiles. Scrum est une méthode orientée équipe de développement. L'ouvrage met l'accent sur les concepts clés : le Team, le Scrum Master et le Product Owner. Les phases organisation, production des versions et déroulement des réunions, les "scrums" sont détaillées...

SCRUM :Succeeding with AgileSucceeding with Agile
Mike Cohn
Addison-Wesley
504 pages (anglais)

Dispo : www.amazon.fr & Format Kindle


Ce deuxième livre propose une explication claire et précise des techniques de planification et d'estimation des projets. Le principe du planning poker est soigneusement décrit et mis en perspective avec les nécessités de la planification...

Agile Estimating And PlanningAgile Estimating And Planning
Mike Cohn
Prentice Hall PTR
368 pages (anglais)

Dispo : www.amazon.fr & Format Kindle


Un très bon livre pour comprendre les principes de la méthode Scrum en particulier et du développement agile en général...

ESSENTIAL SCRUM
A Practical Guide to the Most Popular Agile Process

Kenneth S. Rubin
Editions Pearson€
496 pages (anglais)

Dispo : www.amazon.fr & Format Kindle


En 2 volumes, le guide du corpus des connaissances en management de projet (Guide PMBOK) avec en complément le guide pratique Agile...

Guide du Corpus des connaissances en management de projet + Guide AgileGuide PMBOK + Guide pratique Agile
Project Management Institute
Edition PMI Édition 2018
800 pages

Dispo : www.amazon.fr & Format Kindle


Un très bon livre destiné aux managers débutants ou "improvisés". Vous êtes en charge d'un projet pour la "première fois", ce n'est pas votre métier, comment s'y prendre ? Lire aussi les conseils pour manager de projet débutant...

Project Management for the Unofficial Project Manager
Kory Kogon, Suzette Blakemore
BenBella Books€
256 pages (anglais)

Dispo : Amazon.fr & Format Kindle


Livres à lire Piloter l'Entreprise Innovante...

La prise de décision en équipe ne s'improvise pas. Pour parvenir à ce mode de management délégataire, crucial pour les organisations actuelles, privées comme publiques, un indispensable travail de fond prélable est nécessaire. La méthode SOCRIDE centrée sur les questions incontournables de Confiance et de Reconnaissance est ici expliquée, illustrée et détaillée :

Tableaux de bord du manager innovant, le livreLes tableaux de bord du manager innovant
Une démarche en 7 étapes pour faciliter la prise de décision en équipe

Alain Fernandez
Éditeur : Eyrolles
Pages : 320 pages

Fiche technique Consultez la fiche technique »»»

Pour acheter ce livre :

amazon.fr  Eyrolles.com  ="Fnac.com"

Format ebook : PDF & ePub, Format Kindle

Voir aussi...


Les fiches du dossier: Méthodes Projet

Partagez cet article...

Envoyer le lien de cet article par e-mail    Twitter Facebook Linkedin Retour au début
(total partages cumulés > 65)