Gestion de projet : traditionnelle, itérative ou hybride ?

Comme la plupart des chefs de projet (et des entreprises), vous avez probablement du mal à choisir l’approche de livraison optimale. La plupart d’entre nous reconnaissent que les approches traditionnelles ne garantissent pas une livraison réussie et recherchent toujours de meilleures solutions.

Les techniques de développement agile ou itératif font l’objet de nombreux articles très positifs depuis quelques années, présentées comme une amélioration significative, permettant une réussite plus élevée des livraisons de projets. Par conséquent, comme la plupart des entreprises aujourd’hui, la vôtre se demande probablement où et comment ces techniques de développement agile ou itératif peuvent être utilisées au mieux pour améliorer à la fois les délais et la réussite de la livraison des projets.

En résumé, les techniques de développement itératif planifient, développent et mettent en œuvre les fonctionnalités du projet par petites portions (ou itérations). La clé d’une livraison itérative réussie consiste à ce que chaque petite portion fonctionne efficacement comme un mini-projet distinct, sous l’égide du projet global. Ainsi, chaque itération de mini-projet permet de mieux planifier l’effort nécessaire pour livrer une itération de deux semaines plutôt qu’un plan sur deux ans. De plus, comme nous planifions par tranches de deux semaines, nous pouvons facilement adapter le plan des deux semaines suivantes pour tenir compte de toute modification identifiée.

Étude de cas agile vs. traditionnelle

Je voudrais faire une petite pause pour décrire une situation non technique, où un modèle plus réussi a été obtenu grâce à une approche agile plutôt qu’à un plan traditionnel.

Prenons l’exemple de la planification des activités de toute une journée (il s’agit du projet). Comme pour un projet de grande envergure, cela comporte beaucoup d’incertitudes et de risques : nous ne savons pas ce qui va se passer après le déjeuner, ni ce qui pourrait avoir un impact sur notre plan, mais la tradition veut que nous élaborions un plan complet pour tout ce que nous allons faire chaque heure de la journée, du lever à 6 h au coucher à 23 h.

À 9 h, nous avons du retard parce que les embouteillages ont retardé notre trajet vers le travail. À 10 h, nous sommes convoqués à une réunion d’urgence, et à midi, la seule tâche quotidienne accomplie est d’être arrivé au bureau, avec en plus du retard.

Maintenant, considérons cela comme un projet agile dans lequel nous ne planifions que la prochaine itération : se préparer à quitter la maison (les récits sont donc : douche, petit-déjeuner et enfants déposés à l’école). Tout cela a été livré avec succès, dans les délais et dans le budget.

Nous planifions donc avec confiance la prochaine itération, qui consiste à se rendre au bureau (conduire jusqu’au dépôt d’autobus, prendre le train de banlieue jusqu’à la gare, puis le bus de ville jusqu’au bureau).

Mais cela ne se déroule pas très bien : le premier récit (aller au dépôt d’autobus) rencontre des problèmes de circulation, alors nous modifions le récit utilisateur pour aller directement au bureau et convenons que les deux autres récits peuvent être supprimées du plan d’itération. À l’arrivée, nous planifions l’itération suivante. Mais au milieu du cycle de planification, une nouvelle histoire est ajoutée (la réunion d’urgence), et elle occupera toute l’itération suivante.

Enfin, après le déjeuner, les choses se calment et nous pouvons examiner le backlog et commencer les tâches les plus prioritaires. Nous menons à bien deux itérations traitant les éléments les plus prioritaires dans l’après-midi.

Si nous étions restés fidèles au plan traditionnel, nous n’aurions jamais pu terminer ces éléments prioritaires, car ils auraient été reprogrammés au lendemain à cause du retard du plan provoqué par le trajet vers le bureau.

Quelle est la meilleure approche : agile, traditionnelle ou hybride ?

C’est cette capacité à s’adapter à l’évolution des besoins métier qui fait la force des méthodes agiles ou itératives, et qui explique pourquoi de nombreuses entreprises les adoptent. Cependant, votre entreprise est-elle vraiment prête à passer entièrement à une approche agile ? D’après mon expérience, de nombreux obstacles freinent souvent l’adoption à grande échelle de l’approche agile, en particulier les politiques d’entreprise bien établies qui sont souvent peu compatibles avec les approches agiles.

Il est important d’avoir des politiques exigeant un budget ferme, un énoncé de réalisation des bénéfices et une date cible avant qu’un projet puisse être approuvé, mais elles ne sont pas vraiment agiles. De même, les politiques de mise en œuvre de l’entreprise qui doivent être respectées pour garantir qu’il n’y ait aucun impact sur les opérations existantes sont essentielles, mais certainement pas agiles.

Ainsi, de nombreuses entreprises peinent à conserver certains « processus traditionnels » clés tout en s’adaptant aux méthodes itératives. Pour cela, il existe le modèle de livraison hybride. Certaines parties du projet peuvent être livrées à l’aide de méthodes de gestion traditionnelles, et d’autres de manière itérative.

Modèle de livraison hybride

Le modèle hybride le plus courant que j’ai rencontré prend en charge le lancement et la planification traditionnels du projet, suivis d’une série d’itérations avec des pauses pour les activités de mise en œuvre traditionnelles liées aux versions, puis d’une autre série d’itérations et d’une mise en œuvre traditionnelle.

Dans ce modèle, j’élabore une structure de répartition du travail (WBS) traditionnelle, fondée sur les livrables, qui identifie les livrables essentiels nécessaires dans l’entreprise pour l’approbation du projet, tels que la charte, le plan de gestion et le budget du projet.

Ces livrables initiaux peuvent être élaborés et gérés à l’aide de méthodes traditionnelles pour montrer à la direction que ce projet est pertinent et qu’il s’agit d’un bon investissement de ressources.

Une fois le projet approuvé, il peut alors passer à une approche itérative dans laquelle un backlog d’histoires est tenu à jour, et les histoires les plus prioritaires sont sélectionnées et entièrement développées lors de la prochaine itération. La représentation du projet passe de la vue traditionnelle du diagramme de Gantt à un tableau interactif par glisser-déposer qui permet d’affecter dynamiquement les histoires aux itérations.

À tout moment, souvent au quotidien, le propriétaire du produit peut ajouter, supprimer et modifier les histoires du backlog pour refléter l’évolution des besoins métier.

À la fin de chaque itération, nous faisons une pause et réalisons une évaluation rétrospective des réussites et des échecs, puis nous apportons les modifications nécessaires pour mettre en œuvre les améliorations requises. Ensuite, et c’est le plus important, nous examinons le backlog produit et sélectionnons les histoires les plus importantes comme candidates pour la prochaine itération. Cette approche garantit que le projet travaille en permanence sur les tâches les plus pertinentes et les plus utiles.

Au cours de chaque itération, l’équipe peut appliquer des principes agiles, comme la réunion quotidienne, et discuter de l’état des histoires prévues pour l’itération en cours. Ainsi, l’équipe garde un contrôle total sur le travail réalisé au sein d’une itération, tout en veillant à ce que le projet global reste à jour et disponible pour le reporting d’entreprise sur la capacité en ressources ainsi que sur l’état du portefeuille et des programmes.

L’un des éléments clés des principes agiles est la capacité à mettre en œuvre la solution finale par petites livraisons. Cela a l’avantage de permettre d’utiliser des fonctionnalités préliminaires pour obtenir le plus rapidement possible certains des bénéfices métier attendus.

Cela permet aussi une validation précoce de la solution, afin que des ajustements éventuels puissent être facilement intégrés aux histoires restantes du backlog de produit. Par conséquent, dès qu’un nombre suffisant d’histoires prioritaires ont été terminées au cours des itérations, le projet revient à un cycle traditionnel et exécute les tâches standard de mise en œuvre requises par l’entreprise.

Essayer Microsoft Project gratuitement

Essayez Microsoft Project gratuitement pendant un mois

Découvrez comment

Ces activités de publication et de mise en œuvre seront planifiées et contrôlées à l’aide d’approches traditionnelles et garantiront que les processus définis sont suivis afin d’atténuer tout impact sur les opérations existantes lors de la mise en œuvre de nouveaux projets.

Une fois la première version terminée, le projet revient aux approches agiles et commence à suivre une nouvelle série d’itérations pour poursuivre le développement des récits restants.

Bien que cette approche « par phases » combinant les approches agiles et traditionnelles soit la plus courante, vous pouvez combiner les approches pour répondre à des exigences spécifiques de livraison de projet. Par exemple, j’ai géré un projet qui exigeait un niveau extrêmement élevé de conformité et de validation lors de l’introduction d’un nouveau produit dans un secteur très réglementé. Par conséquent, la majeure partie de mon projet a été planifiée et contrôlée à l’aide de méthodes traditionnelles.

Cependant, le projet comportait une partie d’intelligence économique au cours de laquelle mon entreprise exploitait l’énorme volume de données de performance générées par le système. Cette partie se prêtait mieux à une approche agile. Pour le composant décisionnel du projet (mené en parallèle des travaux traditionnels), nous sélectionnions les récits prioritaires (qui pouvaient être réalisés dans un sprint de trois semaines) et nous menions une itération.

Comme bon nombre de ces récits utilisateurs étaient de type exploration, nous créions souvent de nouveaux récits utilisateurs, soit pour approfondir l’exploration, soit pour créer des rapports de performances précis. Celles-ci étaient simplement ajoutées au backlog pour être examinées lors du sprint suivant.

Avec cette approche, j’avais un planning de projet unique qui me permettait de respecter toutes les étapes de reporting et de conformité réglementaire requises, tout en autorisant une approche extrêmement flexible pour développer le composant de reporting métier non réglementé du projet.

Le fait de regrouper tout le travail dans un seul planning offrait une vision simple de tout ce qui se passait sur ce projet :

Les informations dont j’avais besoin pour gérer l’affectation des ressources vers les tâches les plus appropriées, traditionnelles ou agiles, étaient immédiatement disponibles

La possibilité de créer des rapports d’état hebdomadaires et mensuels performants était à portée de main

L’agilité est une approche de livraison de projet extrêmement puissante qui devrait offrir des avantages significatifs à l’ensemble de la boîte à outils de livraison de projet de votre entreprise. Elle peut être utilisée de façon autonome, dans le cadre d’une approche de livraison par phases, ou intégrée dans une structure de livraison hybride.

La clé consiste à adopter les principes agiles qui aideront votre entreprise à réussir ses livraisons tout en respectant les processus traditionnels qui ont permis à votre entreprise de réussir jusqu’à présent.

Steve Caseley possède plus de 35 ans d’expérience sur Microsoft Project et utilise activement Microsoft Project depuis sa première version. Il est le rédacteur en chef de plusieurs ouvrages consacrés à Microsoft Project et aux meilleures pratiques en gestion de projet. Il est consultant principal chez Sensei Project Solutions, où il aide les grandes entreprises à atteindre l’excellence en matière de livraison de projets à l’aide de la suite Microsoft Project & Portfolio Management (PPM).

PRODUITS ASSOCIÉS
Office 365

Commencez à utiliser Microsoft 365

Accédez à la suite Office que vous connaissez, et tirez parti des outils destinés à renforcer la collaboration et la productivité à tout moment et en tout lieu.

Achetez dès maintenant

Contenu associé

Gérer mon activité

Pourquoi les dirigeants détestent-ils les chefs de projet ?

Ma PME numérique n’offre aucun conseil fiscal ou financier professionnel. Vous devez contacter votre propre conseiller fiscal ou financier pour discuter de votre situation.