Conduire un projet n’est pas chose aisée, de nombreuses études mettent en avant les importants taux d’échec constatés dans les entreprises, en particulier en ce qui concerne les projets informatiques. La méthode est une réponse récurrente à cette situation. Toutefois, la réussite dans le lancement d’un projet, sa gestion et son aboutissement nécessite de prendre en compte quelques fondamentaux souvent oubliés…
#1 Le projet doit être limité dans le temps
Pour commencer, rappelons la définition du projet donnée par le PMI (Project Management Institute), qui présente l’avantage d’être à la fois complète et concise : « Un projet est une entreprise temporaire initiée dans le but de fournir un produit, un service ou un résultat unique ». Le projet est donc temporaire : il a un début et une fin, et ne doit pas être confondu avec les autres processus de l’entreprise. Comme cela sera évoqué plus bas, un projet doit être rattaché à des objectifs précis permettant d’évaluer quand celui-ci a atteint son but, et qu’il peut être arrêté.
Procéder à l’enregistrement des passagers dans un aéroport n’est pas un projet, mobiliser une équipe de travail pour réfléchir à un moyen de diminuer le temps d’attente des passagers lors de l’enregistrement de 10 % en est un.
On utilise parfois les termes (anglais) de « change » et de « run » pour évoquer cette différence : le change évoque le changement, une évolution sur un dispositif ou processus existant, le run évoque son fonctionnement au quotidien.
#2 Le projet doit répondre à un enjeu business, aux objectifs mesurables
Il ne faut pas négliger cet aspect, au risque de passer à côté des vrais enjeux pour l’entreprise. Un projet se doit d’avoir pour ambition de répondre à un enjeu auquel cette dernière fait face.
Celui-ci doit être exprimé clairement, et partagé auprès des différentes parties prenantes. Il peut s’agir de contrecarrer une perte de part de marché, de réduire les coûts, de mettre en conformité un processus avec une réglementation, etc. Dans tous les cas, le driver initial du projet doit être un problème à résoudre, et non pas une solution à mettre en œuvre.
La société UIOP constate des manquements dans le respect de ses délais de paiement auprès de ses fournisseurs. La direction générale mandate alors une équipe projet pour qu’elle mette en place un dispositif permettant d’automatiser le traitement des factures émises par les fournisseurs.
Sur le papier, l’idée ne semble pas mauvaise. Mais est-ce la bonne manière d’appréhender le problème que rencontre l’entreprise ? Ici, le projet est « orienté solution » : l’équipe projet va se concentrer sur la manière d’intégrer un nouveau système. Une manière plus saine d’envisager le projet aurait été de mandater une équipe pour « ramener les délais de paiement à 30 jours ».
Car qui dit que le problème vient uniquement du service facturation ? Si la problématique est ailleurs, elle ne sera peut-être pas détectée par l’équipe projet. La nouvelle solution mise en place risque de ne pas répondre à l’enjeu de l’entreprise : se mettre en conformité avec la loi LME et entretenir de bonnes relations avec ses fournisseurs…
Une fois l’enjeu bien identifié, on pose un objectif clair et mesurable, qui permettra d’évaluer la réussite (ou non) du projet.
#3 Le projet porte sur un périmètre délimité et maîtrisable
Une problématique claire et des objectifs définis, c’est déjà un bon début. Mais avant de se lancer, il reste quelques détails particulièrement structurants à poser.
- Le périmètre, à savoir : qu’est-ce que va faire le projet, mais surtout, qu’est-ce qu’il ne va pas faire. Et chaque partie prenante doit être sensibilisée sur cet aspect, afin que chacun soit conscient de ce que le projet va délivrer et ce sur quoi il n’interviendra pas.
- Le périmètre doit également être maîtrisable par une structure projet. Selon l’ambition de l’entreprise, il s’agira peut-être de plutôt mettre en place un « programme », consistant en un ensemble de projets animés avec une gouvernance ad-hoc.
#4 Le projet est mené par une équipe a qui on a confié un mandat… et des moyens
Dans la continuité du périmètre, le projet doit être doté de moyens (disponibilité des membres de l’équipe projet, budget, etc.). Ce sont ces moyens qui permettront de confirmer la faisabilité du périmètre envisagé, et de bien calibrer les objectifs associés (leur niveau, et le délai pour les atteindre).
Mais cela ne suffit pas. Pour être en mesure de mener à bien son travail, l’équipe projet se doit de recevoir un mandat clair de la direction, au plus haut niveau possible :
- Ce mandat ne doit pas rester un secret, et doit être partagé auprès des parties prenantes qui seront impliquées, pour que l’équipe projet bénéficie d’une liberté d’action pour conduire sa mission.
- C’est d’autant plus important dans les grandes organisations, où les rapports de forces et les luttes internes peuvent rendre la tâche très ardue.
- Selon l’ampleur du projet et les résistances des parties prenantes, l’intervention d’un sponsor qui pourra user de son influence dans l’organisation sera un facteur facilitateur non négligeable.
Les moyens mis à disposition d’un projet vont donc bien au-delà de l’enveloppe budgétaire : la légitimité qui lui est confiée sera déterminante.
Enfin, un projet ne pourra aboutir qu’en présence de mandataires impliqués, et en mesure de décider.
#5 L’état d’esprit des parties prenantes prime sur la méthode
On oppose souvent, malheureusement de façon très caricaturale, « le cycle en V » avec la « méthode Agile ». En gestion de projet, les méthodologies sont importantes, mais il faut être vigilant.
D’une part, parce qu’une méthode n’est qu’une méthode. C’est une boîte à outils, dans laquelle il faut piocher ce dont on a besoin par rapport au contexte dans lequel on se trouve. La méthode donne un fil conducteur dans les différentes étapes du projet, mais il est indispensable de ne pas « s’enfermer » dans celle-ci, quelle qu’elle soit. Dans le cas de l’agilité, je préfère parler de « techniques agiles » plutôt que de « méthode Agile ». La puissance de l’agilité, c’est ce qu’elle suggère en termes de transparence, de communication, de collaboration, de proximité entre les équipes, d’expérimentation, de remise en question régulière et d’amélioration continue. Le succès du projet réside avant tout dans l’état d’esprit de ses acteurs. S’il n’est pas au rendez-vous, les scrum master, user stories, backlog et sprint planning n’y changeront rien.
D’autre part, parce que différentes méthodes, comme le cycle en V et l’agilité, ne sont pas incompatibles et peuvent s’avérer complémentaires au sein d’un même projet. L’approche agile seule sera parfaitement adaptée, par exemple, pour la création d’une application mobile, où des livraisons successives viendront enrichir le produit au fil du temps. Toutefois, quand il s’agit de refondre l’ERP d’une multinationale, avec un potentiel mille-feuilles applicatif imbriqué derrière, et des milliers d’utilisateurs qui y réalisent leur production chaque jour, on voit bien que des livraisons au compte-goutte ne seront pas forcément adaptées. Cela ne signifie pas qu’il faille abandonner les techniques agiles, au contraire : les deux peuvent cohabiter.
#6 La conduite du changement va au-delà du projet
Comme évoqué précédemment, le projet est limité dans le temps. Ce dernier se termine généralement suite au « déploiement » au sein de l’organisation de la solution au problème posé. Ce déploiement nécessite des réflexions préalables pour mettre en œuvre une conduite du changement adaptée, de manière à ce que le changement soit accepté le mieux possible par les personnes impactées. Mais la conduite du changement ne se limite pas à cette étape.
Il y a quelques années, j’ai eu l’occasion de mener un projet de re-engineering de processus auprès d’une équipe d’incident managers. L’enjeu était, entre autres, d’accélérer la prise en charge des incidents. L’équipe a mis en œuvre les ajustements proposés pendant un temps… et le naturel est revenu au galop. Les habitudes ont repris le pas, et les délais de prise en charge que nous avions constaté en baisse, sont repartis à la hausse.
Quelle leçon en tirer ?
Communiquer et convaincre sur le changement est une chose, l’ancrer dans la durée en est une autre. Et c’est un point sur lequel l’équipe projet se doit de travailler, afin de répondre à la question suivante : quels sont les dispositifs qui seront maintenus une fois la structure du projet « démantelée », pour assurer un suivi de l’application des changements, et procéder aux actions correctrices nécessaires ? Chaque entreprise, en fonction des moyens qu’elle sera en mesure de mobiliser, devra poser l’organisation adéquate afin de mesurer l’appropriation du changement dans le temps, et animer les actions d’ajustement nécessaires.
#7 Arrêter un projet : il faut parfois savoir dire stop
Lorsqu’un projet a atteint ses objectifs, et qu’il a bien préparé la suite, celui-ci n’a plus de raison de perdurer et s’arrête. Mais parfois, la situation est plus délicate.
Certains projets sont lancés, par exemple, avec des périmètres mal définis, des moyens inadaptés, des solutions apportées par le top management et qu’il faut faire rentrer au forceps dans les organisations. Ces projets ont parfois du mal à aboutir. Face aux difficultés, il arrive que ces projets soient maintenus dans le temps, avec des remaniements successifs de périmètres, d’objectifs… afin de sauver la face. Mais parfois, il faut accepter que le projet n’ait pas été convenablement lancé, voire que la problématique qu’il tente de résoudre n’existe pas, ou ne justifie pas un tel investissement.
Maintenir un projet a un coût. Arrêter un projet demande du courage mais, en libérant les ressources qui pourront alors être affectées à d’autres projets, l’entreprise en sera gagnante.
Florent Goossens