Tout d’abord, l’objectif de cet article n’est pas de désigner une méthode meilleure qu’une autre. Bien au contraire! Le but est de comprendre dans quel contexte il est préférable d’en appliquer une plutôt qu’une autre. Les deux méthodes sont applicables pour des projets de toute nature et pas nécessairement informatique. Il est vrai que ces deux méthodes de gestion de projet sont nées, toutes deux, dans des contextes de projet informatique. Toutefois, elles ont été étudiées et développées pour s’appliquer à n’importe quel type de projet : BTP, industrie automobile, événementiel….
Nous avons décidé d’étudier ces deux méthodes dans un contexte bien particulier, celui de l’implémentation d’un ERP. Avant même d’en donner les contraintes et particularités, rappelons le fonctionnement des méthodes classique et agile.
Rappel de la méthode Waterfall – plus particulièrement PRINCE2
La méthode Waterfall est née dans les années 70 à l’ère des grands projets manufacturiers. Le principe est simple : une liste d’étapes bien déterminées qui vous amène jusqu’à votre objectif. ll n’y a pas de retour en arrière possible, une fois le projet lancé, l’objectif ne change pas ainsi que les étapes pour y parvenir. C’est clair comme les chutes du Niagara… !
Cette méthode en a inspiré d’autres et il est possible de classer par exemple la méthode PRINCE2 par mis les méthodologies de gestion de projet de type Waterfall. L’état d’esprit est similaire. Effectivement, nous parlons ici de méthode dite séquentielle ou en « cascade ». Chaque étape se suit avec un objectif très clairement défini au début du projet. D’ailleurs, PRINCE2 fait de l’étape initiale appelée « cas d’affaires » une étape fondatrice du projet : la raison même du projet.
PRINCE2 a quant à elle été créée par le gouvernement britannique dans les années 80 pour en faire son référentiel de projet informatique. Par rapport à la méthode Waterfall, elle a apporté une dimension managériale. Cela se traduit concrètement lors de la phase dite de Direction du projet qui implique une décision managériale de poursuivre ou pas le projet après chaque phase de travaux. Il s’agit du Go / No Go. PRINCE2 dissocie bien les étapes techniques chapotées par un chef de projet qui émet un rapport de fin de séquence de travaux permettant à l’équipe de direction de décider de la suite. PRINCE2 a également apporté des notions intéressantes tels que l’assurance qualité, la gestion des risques et la stratégie de communication.
La méthodologie PRINCE2 a fait ses preuves et s’est largement répandue en Europe. L’ensemble de sa terminologie est connu des spécialistes de la gestion de projet qui l’utilisent au quotidien
Rappel de la méthode Agile – plus particulièrement SCRUM
La naissance de la méthode Agile et plus particulièrement celle de SCRUM s’est faite dans un contexte informatique également. En 1986, la méthode s’est appliquée au projet de développement de solutions logicielles. La réflexion de départ est de dire que lorsqu’un projet est de nature complexe et incertain, il ne peut pas être géré de manière prédictive. Bien au contraire, il doit être géré de façon itérative et empirique. Les changements incessants, les désiderata du client ainsi que l’environnement global mouvant exigent une adaptation constante du projet. C’est en cela que Scrum fonctionne selon des périodes de développement courtes appelées Sprint qui ne peuvent excédées un mois et dont l’objectif est défini. Le but étant de répondre à ce que l’on demande de plus en plus : vitesse et flexibilité. Le parallèle avec le Rugby est d’ailleurs à l’origine de l’inspiration : le Scrum ou la mêlée est bien une poussée ordonnée, faite à l’aide d’une équipe réduite visant un objectif court. Sorti de la métaphore, cette méthode évite de partir trop longtemps dans une direction qui n’est plus celle souhaitée ou celle du marché. Contrairement à la méthode séquentielle de PRINCE2, la méthode Scrum est dite alors incrémentale. Les équipes travaillent sur des cycles courts, confrontent leurs développements aux conditions réelles d’activité et apportent des améliorations en continu. A la fin de chaque Sprint, l’équipe Scrum valide l’incrément du produit réalisé pendant le Sprint. Il n’est pas possible de valider un développement inachevé. C’est aussi l’occasion d’inspecter les processus de développement qui ont bien fonctionnés et ceux à améliorer.
La méthode Scrum est conçue pour une équipe réduite dont l’objectif est d’apporter un produit fonctionnel dans un temps limité et dont l’objectif initial peut être différent de celui in fine.
Découvrez la façon BlueBearsIT de la gestion projet fonctionnel
Caractéristiques d’un projet ERP
Le déploiement d’un nouvel ERP est très fréquemment un projet d’envergure et décidé par la direction générale. Il est au cœur de la stratégie d’entreprise et sa réussite conditionne la poursuite de l’exploitation dans des conditions plus efficientes. On retrouve très souvent les mêmes attributs de ce type de projet à savoir :
- Projet dont l’objectif est clair, défini et certain
- Projet dont les étapes sont décrites et connues
- Projet temporaire avec une date fixée, le Go Live
- Projet rassemblant de nombreuses parties prenantes
- Projet à risque budgétaire et risque au changement important
Une première conclusion que l’on peut faire est très certainement le souhait de la direction de contrôler le projet. Très peu de place est laissée à l’improvisation. La confiance est renouvelée à chaque étape clé d’avancement. L’autre point est l’élargissement du projet à de nombreuses entités internes et externes à l’entreprise. Il ne s’agit pas d’une équipe resserrée pouvant être autonome sur sa réalisation. Au contraire, l’équipe projet doit amener avec elle un grand nombre de décideurs et de futurs utilisateurs de sa solution. Une stratégie de communication doit être mis en place. Enfin, le projet n’est valide que lorsque l’ERP est fonctionnel. Il ne peut pas y avoir d’étape intermédiaire dont les livrables pourraient convenir à la direction.
Choix de la méthodologie dans ce contexte ERP
Maintenant que nous avons rappelé le fonctionnement de ces deux méthodologies de gestion de projet ainsi que la nature particulière d’un projet de déploiement d’ERP, il devient plus aisé de synthétiser le choix de la méthode en découpant les rôles de MOA et de MOE.
- En tant que MAO : le rôle est principalement de s’assurer de la réalisation du projet, c’est-à-dire de l’utilisation du nouvel outil par les équipes d’exploitation. La réalisation du projet doit tenir compte des contraintes définies au départ à savoir : contrainte de planification, contrainte budgétaire, contraintes fonctionnelles et contraintes organisationnelles.
A la lecture des avantages de chaque méthode, celle de PRINCE2 nous semble plus adaptée pour y parvenir. En effet, l’équipe projet doit disposer d’une méthodologie claire pour l’aider à faire face à des problématiques de communication, de responsabilités, de niveau de qualité et de respect de la planification.
- En tant que MOE : le rôle est de garantir la réalisation technique de l’ERP. Il s’apparente à un conducteur de travaux qui dans le cas présent, va devoir s’assurer du bon fonctionnement de l’outil. Il y a nécessairement pour la MOE, des phases de développement spécifiques exigés par le client et des tests au fil de l’eau. Ainsi, la méthode Scrum nous semble mieux convenir pour cette partie du projet. En effet, les demandes spécifiques du client peuvent variées. Les développements doivent se faire en un instant court et limité et les tests doivent conforter ou au contraire permettre de corriger rapidement.
En conclusion, nous pensons à un mix à des deux méthodes en réponse à notre question initiale. Le déploiement d’un ERP enchaîne des séquences managériales longues et nécessite un cadre de projet rigoureux pour assurer sa réussite à l’instar de PRINCE2. Et lors des phases itératives de développement spécifiques, la méthode SCRUM semble plus adaptée.
L’utilisation d’une méthode de gestion de projet type PRINCE2 ne s’improvise pas. Elle est d’ailleurs soumise à des certifications. Faites appel à des consultants certifiés tels que ceux de BlueBearsIT pour votre projet ERP.
Contactez Eric – ec@bluebearsit.com
13 rue des Aulnes