Récemment, j’assistais à une formation consacrée aux méthodes et outils du Management de Projet.

Le public présent, d’horizons professionnels divers et principalement hors IT, ne semble guère appréhender les différentes composantes de la gestion de projet. Les questions fusent dès le premier jour :

« Comment différencier un jalon d’une tâche ? », « Comment gérer mon projet si mes ressources sont peu disponibles ? », « Comment maintenir la motivation avec des équipes distantes pour des projets qui durent près d’un an voire plus ?», « Je rencontre rarement mon sponsor et ne sais pas dans quelle direction avancer », …

Toutes ces questions en provenance d’un public intéressé mais désorienté semblent à la fois simples et complexes.

En systémique, le projet d’entreprise peut être vu comme un système dynamique. Le comportement d’un système résulte alors de l’action commune de ses parties. Chaque cycle d’action peut se dérouler de manière très différente des autres et changer au cours du temps; les cycles d’action nécessitant du temps, cela implique des processus de durées différentes.

Nous (acteurs du projet) pouvons influencer le système grâce à différents procédés. L’un d’entre eux, le pilotage, sert à orienter les processus futurs vers des objectifs donnés, à l’aide de directives concrètes.

Je rappellerai ici la définition du projet :

  • Un chantier unique, avec une date de début et une date de fin (décomposable en étapes ou phases)
  • Conduit par une équipe de projet dont les membres peuvent appartenir à différents départements de l’entreprise
  • Ciblé pour atteindre un ou plusieurs objectifs bien définis
  • Avec des contraintes de coût, de calendrier, de ressources et de qualité
  • Avec une priorité identifiée au sein de l’entreprise

D’où une interrogation : en quoi et comment les méthodes Agiles peuvent être un tremplin vers la gestion de projet ?

Souvent, le projet est considéré comme un effort long terme pour lequel le livrable ou le produit final n’est pas matérialisé.

L’Agile permet de se projeter à court terme et de concrétiser rapidement à chaque itération un livrable ou un produit, fusse-t-il incomplet. Le manifeste pour Agile propose ainsi de livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus brefs.

Régulièrement, les équipes projet progressent avec difficulté, par manque de vision. En effet, les acteurs métiers sont impliqués en phase de recueil des besoins puis « oubliés » lors des étapes suivantes jusqu’à la livraison du produit soi-disant final.

Le manifeste pour Agile propose que les utilisateurs ou leurs représentants et les développeurs travaillent ensemble quotidiennement tout au long du projet.

On constate ici que les principes fondateurs de l’Agile mettent en avant la proximité des équipes métier avec les équipes techniques. C’est à l’évidence cette proximité qui fait défaut dans les processus projets « classiques » et qui par la suite génère des incompréhensions …

Toutefois, il reste une question à éclaircir ? Comment sortir les méthodes Agiles du contexte développement logiciel qui semble lui coller à la peau ?

Rendez vous donc en début d’année pour la suite de ce billet. D’ici là, n’hésitez pas à commenter, réagir, …