Comment faire face à des priorités de projet concurrentes ?

Lorsque votre projet est confronté à la concurrence d’autres projets hautement prioritaires, suivez ces étapes pour optimiser les résultats pour votre organisation.

Dealing with competing project priorities  par Bonnie Biafore

https://www.bonniebiafore.com/dealing-with-competing-project-priorities/

Les membres de l’équipe jonglent généralement avec leur travail sur plusieurs projets, de sorte que les priorités concurrentes et le temps limité du personnel ne manqueront pas de perturber les échéanciers des projets.

Vérifiez les priorités du projet auprès de la direction.

Le manque de gouvernance de la part des hauts dirigeants peut entraîner des priorités conflictuelles. La direction peut ne pas être au courant des conflits potentiels à moins que les managers de projet ne les portent à son attention. Présentez les conflits de projets à votre direction et demandez des priorités de projet sans ambiguïté afin que les managers de projet impliqués puissent ajuster leurs échéanciers en conséquence. Si votre projet n’est pas prioritaire, passez aux étapes suivantes de cet article.

Identifiez le champ d’application du produit minimum viable (MVP).

Pour prendre en charge les priorités actuelles de l’organisation, concentrez-vous sur la portée MVP de votre projet. Cela minimisera la pression sur les ressources organisationnelles tout en apportant de la valeur à l’entreprise. Travaillez avec votre équipe de projet pour réévaluer et redéfinir les priorités des tâches qui se concentrent sur le MVP. Vous pouvez différer ou dé-prioriser les tâches non essentielles afin de réduire la portée et la charge de travail. Ensuite, envisagez de reporter ces éléments de portée dé-priorisés sur un projet distinct lorsque les priorités organisationnelles le permettront.

Identifiez les compétences requises pour produire le MVP.

Ajustez la dotation en personnel de votre projet pour fournir les compétences nécessaires pour le MVP. Cet ajustement pourrait réduire la demande de membres seniors de l’équipe de projet et atténuer les conflits de priorité.

Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Travaillez avec d’autres managers de projet et/ou chefs de service pour optimiser les échéanciers.

Comparez les besoins en personnel de vos collègues sur l’ensemble des projets. Vous pouvez trouver des moyens d’optimiser les plannings en redistribuant les tâches ou en partageant les ressources sans sur-allocation.

Ajustez la chronologie de votre projet.

Réévaluez la chronologie de votre projet en fonction de la portée du MVP, des ressources disponibles et du moment où les ressources seront disponibles pour votre projet. Communiquez clairement les changements d’échéances aux parties prenantes afin de manager leurs attentes.

Surveillez de près votre plan révisé.

Faites preuve de flexibilité au fur et à mesure de l’avancement de votre projet et des projets concurrents. Vous devrez peut-être ajuster à nouveau votre plan pour optimiser les résultats globaux de l’organisation. Surveillez et adaptez régulièrement votre plan de projet au besoin.

Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées. En particuliers celles sur Prince2.

Tout manager de projet a dû un jour ou l’autre faire face à des priorités concurrentes.

Comment abordez-vous ce dilemme ?

Quels changements avez-vous apportés aux projets précédents ?

Partagez votre expérience.

Pour en savoir plus sur les priorités des projets, consultez le cours d’Andy Jordan Project Portfolio Management Foundations course.

Quels billets DantotsuPM avez-vous le plus aimé à la rentrée 2023 ?

Déni, feuille de route et culture projet de l’entreprise sont autant d’éléments à comprendre et bien manager pour réussir votre projet.

Manager le déni : voici une douzaine de stratégies dans lesquelles piocher pour mieux engager avec les personnes qui sont dans le déni.

Comment faire face au déni de votre interlocuteur, membre de votre équipe, manager ou toute autre partie prenante de votre projet ?

Qu’est-ce qu’une feuille de route de projet ? Comment en faire une et en quoi est-elle différente d’un diagramme de Gantt ?

« Qu’est-ce qu’une feuille de route de projet ? » par Mike Clayton

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Dans le domaine des projets, la méthodologie de gestion de projet, la gestion des parties prenantes et la planification occupent une place cruciale, et elles ont un impact très significatif sur le résultat final du projet, qu’il soit couronné de succès ou qu’il échoue.

« La culture de l’entreprise est un facteur sous-estimé dans le monde du projet » par Yanis Ioualitene

Boostez la puissance des jalons

Il n’y a pas de limite à l’utilisation que vous pouvez faire des jalons dans vos projets. Ne vous limitez donc pas aux livrables techniques et incluez des jalons pour tous les événements qui sont significatifs pour l’entreprise : Finalisation de processus, tests utilisateurs, pilotes…

Boost the Power of Milestones  par Bonnie Biafore

https://www.bonniebiafore.com/boost-the-power-of-milestones/

Les managers de projet montrent généralement les progrès avec des jalons qui représentent l’achèvement de livrables importants. Mais cela ne fait qu’effleurer la surface de ce que les jalons peuvent visualiser en matière de progression de votre projet.

Voici 5 autres façons de mettre en évidence les progrès réalisés à l’aide de jalons.

#1 – Points de progression sur la chronologie.

Quels sont les jalons auxquels vous allez livrer et nourrir une attente positive ?

En particulier pour les projets plus longs, vous pouvez créer des jalons pour indiquer qu’un quart, la moitié et les trois quarts des tâches de votre échéancier sont terminés.

C’est un excellent moyen de visualiser les progrès à haut niveau de votre échéancier.

#2 – Risques traités.

Un risque majeur appartient-il dorénavant au passé ?

Les risques rendent les parties prenantes nerveuses. Les risques traités sont des éventualités à haut risque qui ont été résolues, soit grâce à des mesures d’atténuation réussies, soit parce que le risque ne s’est pas concrétisé. Créez des jalons pour identifier ces événements positifs dans votre échéancier. En plus d’ajouter ces risques traités à votre suivi des jalons, assurez-vous aussi de mettre à jour le niveau de risque global du projet.

#3 – Réponses positives des parties prenantes aux sondages de satisfaction.

Une façon de mesurer le succès de votre projet est de sonder les parties prenantes sur leur satisfaction à son égard. En fonction des événements entourant le projet, la satisfaction des parties prenantes peut diminuer, en particulier au début du projet avant qu’elles ne voient des résultats. Sondez périodiquement vos parties prenantes. Ensuite, créez un jalon lorsque vous atteignez un niveau prédéterminé de satisfaction des parties prenantes.

#4 – Éléments importants sur le chemin critique qui ne sont pas des livrables.

Tous les éléments du chemin critique ne font pas référence à des livrables. Les éléments importants du chemin critique peuvent inclure des points de rencontre où plusieurs chemins dans l’échéancier du projet se rejoignent comme l’adjonction de membres critiques au projet ou une décision notable d’un organisme de réglementation. Ajoutez des jalons pour afficher ces éléments dans votre planning.

#5 – Dépendances externes.

L’obtention d’autorisations et de certifications mérite d’être notée. La conclusion de négociations contractuelles et autres tâches impliquant des entités externes peuvent être des indices de progrès.

Utilisez les jalons du projet pour les identifier et les suivre.

Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

De nombreux projets techniques utilisent des jalons uniquement pour indiquer l’achèvement des tâches techniques. Pour vous assurer que vos rapports d’avancement sont utiles, incluez des jalons pour tous les événements qui sont significatifs pour l’entreprise, tels que les finalisations de processus ou les résultats positifs des tests des utilisateurs.

Il n’y a vraiment pas de limite à l’utilisation que vous pouvez faire des jalons. Quels autres événements et réalisations soulignez-vous avec des jalons ?

Pour en savoir plus sur les jalons, consultez le cours de Bonnie Project Management Foundations: Schedules course.

Précédent billet de Bonnie Biafore sur ce thème :

Comment bien utiliser des jalons pour suivre la progression du projet ?

J’ai un plan mais tout le monde s’en fiche !

Vous avez un plan mais personne ne s’en soucie, c’est si frustrant !

I’ve got a plan: nobody cares de John Goodpasture

http://www.johngoodpasture.com/2023/09/ive-got-plan-nobody-cares.html

C’est tellement frustrant !

Vous passez beaucoup de temps à planifier, coordonner, évaluer….

Et puis c’est le jour J, les circonstances interviennent, et personne ne suit le plan 😮

(Ou bien, ils en suivent quelques bribes, mais le plan en tant que tel est presque méconnaissable.)

Voici quelques phrases pour dire ce que nous savons tous :

Aucun plan ne survit au premier contact avec la réalité

Mais, si cela est trop évident, que faites-vous ?

  • La première chose à faire est d’avoir un plan de communication prêt avant le début de l’exécution afin de pouvoir toucher toutes les personnes dont vous avez besoin de manière fiable et rapide. Et cette partie du plan devrait être à l’épreuve des balles.
  • La deuxième chose est de savoir à l’avance où tous les décideurs vont être et comment ils vont pouvoir être joints ; et les pouvoirs dont ils disposent.
  • La troisième chose, c’est d’avoir une supervision avec les décideurs tactiques en place là où le travail est fait pour prendre les décisions qui pourraient sauver la situation minute par minute. En d’autres termes, une certaine décentralisation de l’autorité.
  • Une autre chose est d’avoir une redondance intégrée, ainsi que des tampons de temps ou de coût, pour pouvoir remplacer ou combler les points faibles. En d’autres termes, un plan sans marge n’est vraiment pas viable dès le départ.
  • Si « ça » échoue cette fois, sachez quand vous allez réessayer. De toute évidence, la définition d’ « échec » doit être évidente, mesurable, sans ambiguïté, etc.
  • Et si « ça » échoue, préparez un exercice sur les leçons apprises.
  • Le principe du « risque calculé » devrait être intégré : « Lorsque toutes les questions sont examinées et pondérées en valeur, l’avantage de prendre un risque devrait être (au moins) stratégiquement bénéfique, même s’il n’est pas tactiquement bénéfique (la bataille a été perdue, mais l’engagement a permis de gagner la guerre).
Partenaire de DantotsuPM, CERTyou est le spécialiste des formations certifiantes

Libérer la puissance de la collaboration : transformer vos projets grâce à un travail d’équipe efficace par Mohamed Michael Kazak

C’est simple. Vous faites partie du « pack » !

Vous faites partie du « pack » !

La collaboration est le catalyseur qui propulse les projets vers de nouveaux sommets. Dans cet article, je me penche sur les stratégies qui libèrent le véritable potentiel du travail d’équipe et assurent la réussite du processus de développement. Que vous soyez un professionnel chevronné ou un débutant dans le jeu, la mise en œuvre de ces stratégies vous aidera à travailler ensemble efficacement et à fournir des solutions exceptionnelles. En outre, j’explorerai comment la collaboration profite à la fois à l’utilisateur et à l’entreprise.

Établissez des relations solides

L’établissement de robustes relations de travail entre les membres de l’équipe est primordial. Favorisez une communication ouverte et transparente dès le début. Encouragez les interactions régulières, fournissez des commentaires et répondez rapidement aux préoccupations. En établissant la confiance et la compréhension mutuelle, vous posez les bases d’une collaboration efficace tout au long du projet.

Lorsque les membres de l’équipe communiquent ouvertement et se font confiance, cela profite à la fois aux utilisateurs et à l’entreprise. Les utilisateurs bénéficient d’un meilleur soutien et d’un meilleur engagement de la part d’une équipe qui communique ouvertement, ce qui améliore la satisfaction et l’expérience utilisateur. De plus, des relations solides entre les membres de l’équipe favorisent la synergie et la coopération, ce qui se traduit par une productivité accrue, des solutions de meilleure qualité et de meilleurs résultats de projet pour l’entreprise.

Lefebvre Dalloz Compétences est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Participez activement à la planification du projet

Toutes les personnes impliquées dans le projet devraient collaborer lors des séances de planification. Demandez l’avis de l’équipe sur la faisabilité technique, les défis potentiels et les délais de développement. En impliquant tout le monde dans le processus de planification, vous assurez une feuille de route de projet bien informée et réalisable.

La participation active à la planification du projet présente des avantages significatifs pour les utilisateurs et l’entreprise. Les utilisateurs bénéficient de solutions sur mesure qui répondent à leurs attentes et apportent de la valeur, car leurs besoins et exigences sont pris en compte lors de la phase de planification. Pour l’entreprise, l’implication de toute l’équipe dans la planification du projet facilite une compréhension globale des complexités et des contraintes du projet, ce qui conduit à une meilleure allocation des ressources, à des délais réalistes et à une livraison réussie du projet.

Collaborez sur l’amélioration des histoires utilisateur (user stories)

Supportez vos coéquipiers.

L’amélioration des histoires utilisateur est un effort conjoint qui nécessite la contribution de toute l’équipe. Participez à des séances de collaboration pour clarifier les exigences, définir les critères d’acceptation et discuter des approches de mise en œuvre. Encouragez les questions, les idées et les suggestions. Cette approche collaborative favorise une compréhension commune et ouvre la voie à un développement réussi.

L’affinement collaboratif de chaque histoire utilisateur apporte des bénéfices à la fois aux utilisateurs et à l’entreprise. En impliquant l’équipe dans ce processus, les besoins des utilisateurs sont capturés avec précision, garantissant que les solutions répondent à leurs besoins spécifiques et offrent une expérience utilisateur transparente. Pour l’entreprise, l’affinement collaboratif des histoires utilisateur favorise l’appropriation partagée de la solution, réduit le risque de mauvaise interprétation et, en fin de compte, conduit au développement de produits de haute qualité centrés sur l’utilisateur.

Favorisez la communication continue et l’adaptabilité

Maintenir une communication constante tout au long du processus de développement. Partagez régulièrement les mises à jour, les progrès et les modifications apportées aux exigences. Participez activement à des réunions, des revues et des rétrospectives. Epousez une approche adaptable qui permet de faire preuve de souplesse pour répondre aux changements dans les besoins et priorités. En favorisant la communication continue et l’adaptabilité, l’équipe peut rester alignée, relever les défis et prendre des décisions éclairées en totale collaboration.

La communication continue et l’adaptabilité apportent des bénéfices à la fois pour les utilisateurs et pour l’entreprise. Les utilisateurs bénéficient d’être tenus informés de l’avancement du projet, des changements et de tout impact potentiel sur leur expérience, favorisant ainsi la transparence et la confiance. Pour l’entreprise, une culture de communication continue et d’adaptabilité permet de réagir rapidement aux changements du marché, aux commentaires des clients et à l’évolution des besoins. Il en résulte la livraison de solutions pertinentes et compétitives et une amélioration de la satisfaction de la clientèle.

Encouragez la collaboration interfonctionnelle

Organisez des séances de remue-méninges conjointes où les membres de l’équipe se réunissent pour discuter des nouvelles fonctionnalités, des possibilités techniques et des implications business. Encouragez les développeurs à partager leur expertise technique et à proposer des solutions innovantes. De même, les propriétaires de produits peuvent fournir des informations précieuses sur les tendances de l’entreprise et les besoins des utilisateurs. En favorisant la collaboration interfonctionnelle, vous tirez parti des connaissances collectives de l’équipe et générez des idées plus robustes.

La collaboration interfonctionnelle profite à la fois aux utilisateurs et à l’entreprise. En favorisant la collaboration interfonctionnelle, les utilisateurs bénéficient des diverses perspectives prises en compte lors des séances de brainstorming. Cela garantit que des solutions innovantes sont développées pour relever des défis commerciaux complexes et offrent une expérience utilisateur améliorée. Pour l’entreprise, la collaboration interfonctionnelle tire parti des connaissances et de l’expertise collectives de l’équipe, ce qui conduit à la génération d’idées et de solutions plus solides. En fin de compte, cela stimule la croissance de l’entreprise, améliore la compétitivité des produits et augmente la satisfaction des clients.

Mettez l’accent sur l’assurance qualité et les tests

L’assurance qualité et les tests sont cruciaux pour tout développement logiciel réussi. Collaborez avec les développeurs pour établir des processus de test musclés et assurer une couverture complète. En donnant la priorité à l’assurance qualité, les développeurs et les propriétaires de produits peuvent fournir des solutions fiables et hautement performantes.

La priorisation de l’assurance qualité apporte des avantages significatifs aux utilisateurs et à l’entreprise. Les utilisateurs reçoivent des solutions fiables et performantes à la suite de tests approfondis, garantissant une expérience transparente et minimisant les problèmes. Pour l’entreprise, mettre l’accent sur l’assurance qualité conduit à une plus grande satisfaction des utilisateurs et des clients, à une adoption accrue par les utilisateurs et à une meilleure réputation, contribuant ainsi au succès à long terme. Un avantage secondaire est la réduction des correctifs, d’où des économies de coûts.

Favorisez une culture d’amélioration continue

Tout le monde devrait continuellement chercher des moyens d’améliorer la collaboration et les processus de développement. Réfléchissez à ce qui s’est bien passé et identifiez les domaines à améliorer. Encouragez les commentaires et mettez en œuvre des informations exploitables pour améliorer la collaboration et les résultats globaux du projet.

La culture de l’amélioration continue profite à la fois aux utilisateurs et à l’entreprise. Les utilisateurs bénéficient de l’amélioration continue des processus de collaboration, ce qui conduit à une meilleure communication, à une plus grande implication des utilisateurs et, en fin de compte, à des solutions meilleures qui répondent à leurs besoins en constante évolution. Pour l’entreprise, une culture d’amélioration continue favorise l’innovation, l’efficience et l’efficacité, ce qui se traduit par une productivité accrue, de meilleurs résultats de projet et un avantage concurrentiel sur le marché.

Défis potentiels et solutions

Au cours du processus de développement, divers défis peuvent survenir qui nécessitent une collaboration efficace entre les développeurs et les propriétaires de produits.

Prenez un exemple où le défi consiste à choisir entre deux approches différentes pour créer des tâches dans le progiciel pour le futur utilisateur : Utiliser des flux ou tirer parti de canevas/macros prédéfinis.

Dans ce scénario, l’utilisation de flux pour créer des tâches peut fournir une expérience conviviale, permettant aux utilisateurs de créer facilement des tâches avec une interface guidée. Cependant, les flux nécessitent un effort de développement important, y compris la conception du flux, la mise en œuvre de la logique et les tests de la fonctionnalité. Cette approche peut nécessiter plus de temps de développement en amont, mais peut fournir une expérience utilisateur transparente.

D’un autre côté, l’utilisation de canevas ou de macros pour la création de tâches peut potentiellement réduire le temps de développement requis. Les canevas ou les macros fournissent des modèles prédéfinis ou des séquences automatisées d’actions que les utilisateurs peuvent suivre pour créer des tâches. Cette approche peut nécessiter moins d’efforts de développement, car elle repose souvent sur des fonctionnalités existantes du progiciel. Cependant, cela peut nécessiter une formation supplémentaire des utilisateurs pour s’assurer que les utilisateurs comprennent comment utiliser efficacement ces canevas ou macros pour la création des tâches.

Face à ce défi, les développeurs et les propriétaires de produits doivent s’engager dans des discussions collaboratives pour évaluer les avantages et les inconvénients de chaque approche. Tenez compte des exigences spécifiques du projet, des besoins des utilisateurs et des implications à long terme.

En s’engageant dans une communication ouverte et en comprenant les compromis, les développeurs et les propriétaires de produits peuvent prendre une décision éclairée qui s’aligne sur les objectifs du projet et équilibre l’expérience utilisateur, le temps de développement et la flexibilité à long terme.


Un développement réussi dans les projets logiciels nécessite une forte collaboration entre les développeurs et les propriétaires de produits.

  • Établissez de solides relations.
  • Participez activement à la planification du projet.
  • Collaborez à l’amélioration de la relation utilisateur.
  • Favorisez la communication continue et l’adaptabilité.
  • Encouragez la collaboration interfonctionnelle, en mettant l’accent sur l’assurance qualité et les tests.
  • Favorisez une culture d’amélioration continue.

Les développeurs et les propriétaires de produits peuvent travailler ensemble efficacement pour fournir des solutions exceptionnelles.

En outre, en relevant les défis potentiels, tels que l’évaluation de différentes approches pour des fonctionnalités spécifiques, les développeurs et les propriétaires de produits peuvent prendre des décisions éclairées qui trouvent un équilibre entre l’expérience utilisateur, l’effort de développement et la flexibilité à long terme.

Grâce à une collaboration efficace, les projets logiciels peuvent livrer leur plein potentiel et obtenir des résultats transformateurs pour les utilisateurs et pour l’entreprise.


Mohamed Michael Kazak

Mohamed Michael Kazak dispose de plus d’une décennie d’expérience à travers diverses industries et plusieurs pays, avec un riche parcours en transformation technologique, gestion de projet, et excellence commerciale. Actuellement, Mohamed Michael occupe le poste de Salesforce Service Product Owner chez Imerys SA, où il dirige les initiatives liées à la digitalisation des activités Service Client Salesforce. Il a lancé plusieurs produits Service Cloud réussis qui ont nettement amélioré l’efficacité du service client et la satisfaction client. Ayant travaillé pour des organisations telles qu’EY et Deloitte, il a géré des équipes diverses et dirigé des projets de transformation avec un focus sur la création de valeur et la satisfaction des besoins des utilisateurs. En tant qu’Administrateur Certifié Salesforce, Mohamed Michael apporte une compréhension approfondie de la manière dont la technologie apporte des résultats commerciaux optimaux.

« Qu’est-ce qu’une feuille de route de projet ? » par Mike Clayton

Qu’est-ce qu’une feuille de route de projet ? Comment en faire une et en quoi est-elle différente d’un diagramme de Gantt?

https://onlinepmcourses.com/what-is-a-project-roadmap-how-to-make-one-and-how-is-it-different-from-a-gantt-chart/

Dans cette vidéo, Mike répond à la question « Qu’est-ce qu’une feuille de route de projet ? » et il regarde aussi pourquoi vous les utilisez, en quoi elles diffèrent d’un diagramme de Gantt et comment créer votre feuille de route.

Le « quoi » d’une feuille de route de projet

Qu’est-ce qu’une feuille de route de projet ?

Une feuille de route de projet est un aperçu visuel des objectifs du projet, de la réalisation des bénéfices, des principaux axes de travail et des étapes clés, présentés sur une chronologie.

C’est un outil stratégique, donc vous pouvez également inclure d’autres choses qui vous aident à créer une compréhension de haut niveau de votre projet. Ainsi, vous pouvez ajouter des éléments tels que les ressources, les risques, les dépendances et les livrables.

Pourquoi utilisez-vous les feuilles de route de projet ?

Il existe de nombreuses bonnes raisons d’utiliser une feuille de route de projet. Elle vous aide à :

  • Articuler vos idées
  • Clarifier ces idées
  • Identifier les priorités du projet, les étapes clés et les dépendances à l’intérieur et à l’extérieur de votre projet
  • Vous concentrer sur les objectifs stratégiques
  • Transmettre des informations importantes rapidement et en une seule vue pour des séances d’information et des discussions stratégiques. Cela vous aide à communiquer vos idées et vos attentes à votre équipe et à vos parties prenantes.
  • Coordonner les ressources avec d’autres équipes.

En quoi une feuille de route de projet diffère-t-elle d’un diagramme de Gantt ?

Un diagramme de Gantt fonctionne généralement au niveau de la tâche, avec des regroupements de celles-ci. Son but est de visualiser tous les détails de votre plan.

Les diagrammes de Gantt ont plus de 100 ans…

Les feuilles de route fonctionnent au niveau des livrables fonctionnels complets et des résultats significatifs pour le projet (parfois avec des explications qui identifient leurs composants clés). Elles offrent une vision stratégique de haut niveau qui évite les tâches basiques quotidiennes.

Donc, la différence est en grande partie une question de granularité.

En outre, les diagrammes de Gantt ont des échelles de temps strictement linéaires (c’est-à-dire que la même longueur sur le graphique signifie toujours la même quantité de temps).

Les feuilles de route n’ont pas ce formalisme, de sorte que vous pouvez choisir d’avoir une approche des vagues flexibles où les délais à court terme sont affichés avec plus de détails et prennent plus d’espace que les événements à plus long terme qui sont compressés sur de plus petits espaces.

Parce que ces échéanciers et feuilles de route ont tous deux un objectif différent, mais précieux, vous devriez les utiliser tous les deux.

Tout d’abord, développez votre feuille de route pour donner un aperçu stratégique de votre projet. Ensuite, détaillez les objectifs stratégiques et les jalons jusqu’au niveau de la tâche dans le plan de projet.

Le « comment » d’une feuille de route de projet

Qu’est-ce qui entre dans une feuille de route de projet ?

Ce que vous mettez dans votre feuille de route doit se concentrer uniquement sur ce qui est le plus essentiel. Rappelez-vous, il s’agit d’une vue d’ensemble stratégique de haut niveau. Donc, cette liste est celle des éléments que vous pouvez considérer.

Mais n’incluez que ce qui compte vraiment pour vous, vos parties prenantes et votre projet.

  • Buts, objectifs et autres mesures de réussite
  • Étapes clés, telles que les dates de livraison critiques ou les délais internes et externes
  • Échéancier du projet
  • Livraison des bénéfices majeurs du projet et de ses principaux livrables.
  • Ressources et personnes clés
  • Dépendances
  • Initiatives importantes, activités, principaux axes de travail et phases du projet
  • Risques majeurs du projet

Comment créer votre feuille de route de projet

Développez votre feuille de route de projet avant de créer un plan de projet détaillé. C’est un excellent outil pour briefer votre équipe lors de votre réunion de lancement de projet.

Lorsque vous créez votre feuille de route de projet, voici les étapes essentielles :

  1. Découpez votre projet en phases et en flux de travail.
  2. Cartographiez-les par rapport à une chronologie par trimestres ou, tout au plus, en mois.
  3. Identifiez les dépendances entre les flux ou phases de travail et entre ceux-ci et des événements externes.
  4. Identifiez les principaux bénéfices et livrables, et quand ils seront livrés (fin de trimestre ou fin de mois). Ajoutez les autres jalons majeurs du projet.
  5. Ajoutez des informations supplémentaires dont les membres de l’équipe et les autres parties prenantes peuvent avoir besoin. Envisagez d’avoir des vues ciblées qui mettent en évidence des informations différentes en fonction des parties prenantes.
  6. Tenez votre feuille de route à jour tout au long du projet.

La vidéo de Mike Clayton

Modèles de feuille de route de projet pour PowerPoint, SLides ou Keynote : Les illustrations de la feuille de route du projet dans cette vidéo ont été adaptées à partir de modèles standard de SlideEgg.

Vous pouvez obtenir votre propre abonnement SlideEgg ou  votre offre d’accès à vie.

Négociation des échéances des projets

Avez-vous déjà eu à négocier une date butoir de projet avec votre sponsor de projet ? C’est intimidant, mais être bien préparé facilite l’interaction.

Negotiating project deadlines par Bonnie Biafore

https://www.bonniebiafore.com/negotiating-project-deadlines/

Voici mes 4 meilleurs conseils pour vous préparer à négocier une date butoir.

#1 – Identifiez ce qui motive la date butoir.

Posez des questions sur les échéances souhaitées et sur ce qui motive ces dates. Il peut s’agir d’un aspect légal, d’une volonté de battre un concurrent ou de pressions exercées par le conseil d’administration. En comprenant les contraintes liées aux délais, vous pouvez aborder de front ces éléments. Ajuster le contenu ou faire appel à des experts pourrait vous aider à respecter une date butoir.

#2 – Faites des recherches sur votre projet.

Pour négocier efficacement, vous devez en savoir le plus possible sur le projet, en particulier l’échéancier du projet, les défis en matière de personnel, le périmètre et les risques potentiels. Ne discutez pas des délais avant d’avoir terminé vos devoirs, afin que votre discussion puisse être plus éclairée et significative. Si votre négociation identifie d’autres éléments ou risques, demandez du temps pour compléter vos rechercher.

Donner un délai sans faire de recherche est irresponsable. Ce serait comme si votre mécanicien automobile vous disait ce qui ne va pas avec votre voiture et estimait le travail à €1200 sans même la regarder. Vous ne feriez probablement pas confiance à cette estimation ! Alors, regardez sous le capot avant d’accepter une estimation et une date butoir de projet.

#3 – C’est le projet du sponsor !

Assurez-vous que le sponsor comprend les risques qu’il endosse.

La négociation devrait consister à partager l’information et à trouver la meilleure solution. Le résultat pourrait être une échéance de projet agressive. N’oubliez pas que ce n’est pas le travail du chef de projet d’empêcher le sponsor de prendre des risques. Votre travail consiste à vous assurer que le sponsor comprend les risques qu’il endosse et les impacts associés. Essayez de proposer des solutions alternatives qui pourraient rendre l’échéance plus réalisable. Cela peut inclure la dotation en personnel, la réduction de la portée ou la réalisation du projet par étapes.

#4 – Documentez les hypothèses.

Tenez votre journal des hypothèses à jour et visible de votre équipe et de votre sponsor.

Une fois que vous avez convenu d’une date butoir, assurez-vous de bien capturer toutes les hypothèses que vous avez faites, telles que les niveaux de dotation en personnel opérationnel. Souvent, les membres du personnel opérationnel sont retirés d’un projet pour effectuer leurs tâches quotidiennes, ce qui a un impact sur l’avancement de votre projet et met en péril la date butoir. D’autres hypothèses pourraient être la disponibilité de certaines technologies ou de certains fournisseurs pour aider à l’exécution des livrables du projet. Assurez-vous que votre sponsor et les principales parties prenantes comprennent ces hypothèses. Suivez les progrès par rapport à ces hypothèses et signalez quand un écart se produit. De cette façon, vous pouvez réagir rapidement pour apporter des corrections afin de respecter votre délai.

Avez-vous d’autres conseils pour négocier les délais? Avez-vous rencontré des obstacles avec des délais que vous ne savez pas comment résoudre?

Cet article appartient à la série de bulletins de Bonnie : Project Pointers, qui compte plus de 33 000 abonnés. Si vous aimez cet article, vous pouvez vous abonner pour recevoir des notifications lorsqu’un nouvel article en anglais est publié. Si vous souhaitez en savoir davantage sur les sujets dont Bonnie parle dans ces bulletins ? Regardez  ses cours sur LinkedIn et écoutez ses émissions en direct LinkedIn Office Hours.


Les dates butoir sont un sujet critique dans le management des projets et plusieurs billets précédemment publiés traitent de ce sujet.

Fausses échéances de temps dans les projets

Des délais à respecter ? Utilisez les blocs de temps ! par Jeff Ball

Comment manquer une date butoir (avec professionnalisme sinon fierté) !

Comment (ne pas) manquer une date butoir

Manqué de si peu

Faites la planification, mais jetez les plans !

Je vous concède volontiers que la position est exagérée, mais elle contient cependant beaucoup de véracité.

Comme ce blog est centré sur le management de projets, j’y ai bien sûr publié bon nombre de billets sur le planning. En voici quelques-uns que vous voudrez peut-être relire ou découvrir.

Comment découpez-vous votre travail ?

Les avantages des lignes de référence de base dans le management de projets.

Comment évaluer une grosse demande de modification de projet

« Garantir le succès du projet : vers la Project Omniscience » par Cyril Verbrugghe

5 bénéfices du diagramme réseau de planification de projet (Schedule Network Diagram)

Dans les délais prévus

Comment découpez-vous votre travail ?

et bien d’autres…

Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées. En particuliers celles sur Prince2.

La gestion de projet assistée par l’Intelligence Artificielle par Zidane Zait

L’impact de l’Intelligence Artificielle (IA) sur la gestion de projet.

Depuis des milliers d’années, l’homme réalise des projets, comme nos ancêtres qui fabriquaient des outils et allaient chasser le gibier, construisaient les pyramides d’Égypte, bâtissaient la muraille de Chine, etc.

Ces projets ont été réalisés avec le savoir-faire et les moyens existants dans ces époques lointaines.

La triple Contrainte
la triple Contrainte

Au fil du temps, les connaissances en gestion de projet s’accumulent, les outils et les moyens se perfectionnent et la gestion de projet s’améliore en optimisant de mieux en mieux les principaux composants d’un projet à savoir son périmètre (scope), son coût et les délais de sa réalisation.

A partir de 1950, le domaine de la gestion de projet a connu une évolution rapide et a commencé à se structurer et à se standardiser avec notamment :

  1. La généralisation de l’’utilisation du diagramme de GANTT créé en 1910 pour notamment planifier, suivre et coordonner les différentes tâches d’un projet,
  2. L’invention du réseau PERT en 1958 (Program Evaluation Review Technique, « technique d’évaluation et d’examen de programmes ») pour l’ordonnancement et la planification du projet,
  3. La création du PMI® (Project Management Institute) en 1969 pour développer des compétences et expertises en gestion de projet,
  4. La création de logiciels comme MS Project et Primavera pour automatiser les calculs avec une meilleure maîtrise de la gestion et du suivi des projets,
  5. La généralisation de l’utilisation des méthodes agiles à partir de 2001 pour tout type de projets imprévisibles, notamment les projets technologiques, d’exploration, innovants et créatifs. Ces méthodes s’avèrent très efficaces pour la bonne réussite de ce type de projets.

En gestion de projet et les chefs de projet sont constamment à la recherche d’outils et de techniques innovants pour améliorer les processus de planification, d’exécution et de suivi.

Ce souci a poussé les acteurs des projets à s’intéresser également à l’intelligence artificielle (IA) avec en tête la solution ChatGPT d’OpenAI ou son concurrent Bard de Google.

Pour rappel l’objectif d’un projet de l’IA est d’imiter le cerveau humain. ChatGPT ou Bard utilisent des réseaux de neurones artificiels pour traiter des données fournies et générer de nouvelles données. Grâce à l’apprentissage continu, ces chatbots s’améliorent et se perfectionnent en continu. Entre autre, ils comprennent le langage écrit et parlé, et ils peuvent fournir des réponses cohérentes et pertinentes en temps réel.

Le cabinet Gartner estime que d’ici 2030, 80% des tâches actuelles de la gestion de projet, pourraient être automatisées grâce à l’Intelligence Artificielle.

Voyons comment ChatGPT, considéré comme un outil révolutionnaire aujourd’hui va impacter le domaine de la gestion de projet.

Il peut être chargé de :

  1. Répondre aux questions: Répondre automatiquement à tout type de questions de clarification, de conseil, de rédaction, de définition et fournir des commentaires précis.
  2. Planifier : Créer des plannings de projet. Par exemple la génération automatique des tâches, des relations entre tâches, les échéanciers.
  3. Faciliter la communication: Faciliter la communication entre toutes les parties prenantes. Créer des contenus, de la documentation, collecter des données, les résumer et les diffuser. Exemple : Rédiger des E-mails, les envoyer à des destinataires précis et répondre à des E-mails.
  4. Générer des plans: Générer des plans de documents, de réunions, de présentations…exemple le plan d’une présentation de projet, de la réunion Kick-Off.
  5. Transcrire et diffuser de l’information : La transcription des réunions pour convertir la vidéo en texte, l’analyse des données, la préparation de résumés et leur diffusion.
  6. Générer des idées : La génération d’idées et de suggestions à partir des données historiques lors des brainstormings.
  7. Gérer les risques: Identifier et évaluer les risques potentiels et suggérer des stratégies de prévention.
  8. Suivre le projet : Suivre l’avancement du projet avec des indicateurs de performance et alerter en cas de dérives.
  9. S’interfacer avec MS Project: ChatGPT peut être incorporé à ce logiciel de gestion de projet pour affecter des tâches à des personnes, suivre l’évolution du projet, fournir des mesures de performances,  réaliser des reportings et les diffuser aux parties prenantes.

A noter que ChatGPT a  été entrainé avec des données allant jusqu’à septembre 2021, ses analyses et réponses sont donc limitées à cette date.

ChatGPT et d’autres solutions basées sur l’IA aident les chefs de projets à mieux planifier, mieux exécuter et mieux suivre les projets, ce qui permettra d’augmenter grandement le taux de succès des projets.

ChatGPT est là pour soutenir le chef de projet, et va réduire grandement sa charge du travail. Le chef de projet va se consacrer à la gestion des relations humaines, aux jugements et à la prise des décisions.

Zidane Zait

Zidane Zait

Zidane Zait, coach Agile et formateur Scrum, enseigne aux équipes l’agilité, l’Agile Framework Scrum et Agile MS Project. Son objectif est de faciliter le développement d’un esprit agile, la réalisation de solutions de valeur, la collaboration, l’auto-gestion des équipes, l’amélioration continue ainsi que l’engagement, la passion et l’enthousiasme envers ces approches.

Billets les plus lus sur le blog du management de projets DantotsuPM au mois de Juin 2023 : Les personnes que vous n’aimez pas, Managez votre manager ! et Pilotez plusieurs projets sans prise de tête.

Comment traiter avec les personnes que vous n’aimez pas en 7 étapes.

Nous avons tous des gens que nous n’aimons pas, cependant, si vous utilisez ces compétences relationnelles clés pour les manager, vous pouvez obtenir les mêmes résultats.

8 conseils pour manager votre management !

Le pilotage de plusieurs projets en mode “zéro prise de tête” par Valérie Narcisse de Yookkan

Les équipes projet ont besoin de s’organiser, suivre et gérer leurs projets, tâches et flux de travail de manière efficace.

Chef de Projet : Acuity is the key ! (L’acuité est la clé !) par Olivier Husser

Comparer un chef de projet à un « chef d’orchestre » est plutôt valorisant, sympathique, et assez parlant.

Sauf que la métaphore étant posée, elle ne dit rien de très précis sur les qualités et le rôle d’un chef de projet ou d’orchestre, ou tout du moins ce que j’ai pu en lire est généralement une projection de certaines compétences clés du chef de projet sur le chef d’orchestre, plus que l’inverse.

S’il est plaisant de pratiquer une analogie entre ces deux postes en termes de direction-coordination, peu d’entre nous savent diriger un orchestre ou comprennent comment et sur la base de quelles qualités opère cette fonction.

En réalité, l’interprétation d’une œuvre symphonique préexistante par des musiciens virtuoses, selon une écriture suivie à la lettre et connue sur le bout des doigts est très éloignée des projets que nous avons en charge.

La comparaison reste intéressante mais je crois qu’on oublie l’essentiel :

Ce qui fait un bon chef d’orchestre, ce n’est ni la baguette, ni la partition, ni même la qualité des musiciens, c’est son acuité.

Cette sensibilité élevée qui permet d’appréhender le subtil et de conduire de manière fine en harmonie avec des « parties-prenantes » sur une « recette » définie, une partition préexistante.

Louis de Funès ne joue pas le chef d’orchestre dans « la Grande Vadrouille ». Il est ancien musicien professionnel et a, en 1966, plus de quarante années d’expérience en tant que pianiste.

Il me semble que notre époque techno-centrée se concentre beaucoup (trop?) sur les méthodes (Agile, Prince, Prédictive, Cascade…) et les outils informatiques associés (MS Project, Jira…) au point d’oublier la substance basale de la gestion de projet : l’acuité.

Aussi, le bon chef de projet n’est-il pas le plus virtuose en technique ni le plus doué sur Excel, mais celui ou celle dont l’acuité permet d’observer, analyser, comprendre et coordonner. De manière aigüe.

L’observation est le préliminaire de toute science.

Observer pour comprendre

(crédit : https://www.linkedin.com/in/fix-dessinateur-9366b9/)

Galilée, Pythagore, Einstein… tous, en leurs temps et selon les moyens techniques à leur disposition, savaient la nécessité d’observer.

Léonard de Vinci préconisait par exemple la méthode Observation, Expérience, Induction, Déduction.

L’accélération de la transformation digitale nous permettrait-elle d’abandonner notre acuité ?

Au même titre qu’aucun tournevis ne sait visser, aucun logiciel de projet ne sait coordonner. De même qu’aucune méthodologie projet ne fonctionne par elle-même.

Plus les projets deviennent complexes, plus il devient réflexe de nous fier à des outils (prototypage, coordination, décisionnel, reporting…) moins nous sommes centrés sur la vue d’ensemble et moins nous gardons l’œil sur l’objectif, la cible.

Et il ne s’agit pas simplement de regarder pour voir mais de regarder pour comprendre, écouter pour comprendre. Les outils et méthodes arrivent ensuite par leur support.

L’observation est essentielle et devient particulièrement puissante quand elle prend en compte simultanément la « big picture » ainsi que les détails les plus fins.

  • Serions-nous arrivés dans une ère de perte de l’acuité à mesure que des outils ne serviraient plus à aider ou confirmer celle-ci mais s’y substitueraient ?
  • Pourrions-nous désormais nous le permettre ?
  • La comparaison au chef d’orchestre tiendrait-elle toujours ?

Y a-t-il un pilote dans le projet ?

Prenons peut-être l’exemple d’un pilote d’avion : son acuité est primordiale, aussi bien dans un petit Cessna monomoteur d’école que dans le dernier Rafale bourré d’informatique.

La gestion de projet risque-t-elle moins le crash qu’un pilote d’avion myope sans lunettes qui ne se fierait qu’à ses instruments flous ?

Alors, oui, nous croisons parfois ces vidéos d’un passager capable de faire atterrir un Boeing sans aucune connaissance de pilotage. Mais que ce soit en simulateur ou dans le réel, ce dernier est totalement guidé par quelqu’un qui connaît les outils et procédures à la lettre, mais surtout, l’acuité du passager est maximale afin de bien entendre les indications radio et d’actionner le bon levier au bon moment.

Cet exemple se transposerait plus difficilement s’il s’agissait de remplacer un chef d’orchestre de la même manière, l’interprétation tomberait probablement à plat.

Je lis beaucoup de sujets sur la gestion du risque en tant que chef de projet.

  • A-t-on déjà quantifié l’absence ou les lacunes d’observation et donc de compréhension de ce qui est simplement visible ?
  • Quel est celui qui regarde tout ce qui est monitoré et comment le comprend-il ?
Re-focaliser les équipes sur la cible plutôt que sur la flèche !

Issu de l’industrie du Broadcast et chef de projet depuis les années 90, j’ai vu les process et les équipes se remodeler au fil des innovations technologiques permanentes. Nous ne parlions pas « d’adaptation au changement », nous le faisions. J’ai fréquemment été témoin de la fascination pour les nouveaux outils au détriment du résultat final. Il m’a régulièrement fallu re-focaliser les équipes sur la cible plutôt que sur la flèche. Qu’elles ne demeurent pas aveuglées ni centrées sur les innovations.

La chance d’un secteur dont le livrable est audio et visuel est qu’on ne peut pas se permettre de totalement « oublier » d’observer. Il demeure pourtant des accidents industriels au cinéma, à la télévision et dans les créations de commande :

Quelqu’un n’a pas vu le désastre arriver malgré des tableaux Excel impeccables, de la technologie de pointe et de la méthode.

Mettre la charrue avant les bœufs n’est jamais un projet viable.

« Cart before horse » en anglais.

Lorsque que j’ai, un peu par hasard, intégré un secteur industriel très différent du mien au sein d’une multinationale spécialisée dans le déploiement de technologies ferroviaires j’ai été très surpris.

En dépit des exigences manifestes en termes de coûts, délais, logistique, client ou équipes projetées un peu partout géographiquement il n’y avait en apparence aucune coordination.

N’occupant pas moi-même de poste de pilotage sur ce contrat, ma vue parcellaire des activités aurait pu me tromper dans mon appréciation à priori de la situation, cependant, les différentes visios de cadrage et de suivi que j’entendais et qui se déroulaient dans le bureau jouxtant le mien me confirmèrent très vite l’absence d’organisation et sans doute de méthode. Pendant que certains intervenants brassaient de l’air, d’autres, chefs de projets, énuméraient les postes de leur tableau MS Project comme s’ils tentaient de compléter les lignes du jeu Tetris.

Le centre d’attention de ces réunions était un logiciel à remplir, pas une activité complexe à coordonner. Ou alors considéraient-ils que remplir une ligne d’un logiciel revenait à coordonner ?

En deux ans, ces chefs de projet ne sont jamais venus voir le réel de l’activité qu’ils avaient en charge de conduire. Nous avons par contre du faire face à des charrues placées avant les bœufs, de la logistique qui ne suivait pas, des équipes perdues qui couraient comme des poulets sans têtes, des points d’arrêt imposés par le client mécontent, probablement des millions d’euros de marge partis en fumée

Des millions d’euros de marge partis en fumée…

De mon côté, bien que ne possédant qu’un aperçu très fragmentaire de l’ensemble, je me hâtais de créer mon propre tableau de suivi afin de pouvoir potentiellement endiguer et prendre en charge des problèmes divers qui ne manqueraient d’arriver jusqu’à notre équipe. Ce tableau, actualisé à la volée, simple et visuel, nous sauva plus d’une fois.

Pour revenir à l’allégorie du chef d’orchestre sur cette anecdote, nous avons interprété une véritable cacophonie, avec professionnalisme et sérieux – selon la gouvernance opérée.

Les crashs étaient courants.

Depuis toujours, le boulanger regarde son pain, il écoute le craquement de la croûte et sent son odeur pour considérer qu’il est bon. Avant même de le goûter.

Transformer son pain en « baguette connectée 4.0 » reviendrait-il à mettre en sourdine ses sens au profit d’un outil informatique de pilotage ou de prise de décision ? Serait-il toujours Boulanger ? Mais surtout, la baguette serait-elle bonne ?

On pourra me trouver caricatural.

Pour moi la caricature, ce sont les formulaires en ligne pleins de bugs ou les applis dysfonctionnelles avec des UX/UI incongrues : tout a pourtant été testé et le code doit sûrement être magnifique, mais personne n’a VU que ça ne fonctionne pas…

Un chef de projet doit observer pour comprendre, pas pour répondre.

Ne déléguons pas notre réflexion aux machines et méthodes.

Acuity is the key.

Olivier Husser

Olivier Husser

Chef de projet dans l’industrie du broadcast et de la prestation audiovisuelle depuis 1997.

Voici que répondre à certaines préoccupations sur SAFe…

SAFe reconnaît et respecte que de nombreuses organisations en transition vers des pratiques agiles ont encore un état d’esprit traditionnel. Par conséquent, beaucoup de matériel dans SAFe peut paraître inacceptable pour les agilistes confirmés.

Addressing some SAFe concerns par Michael Küsters

https://failfastmoveon.blogspot.com/2023/05/addressing-some-safe-concerns.html

Très souvent, je rencontre des préoccupations avec SAFe (Scaled Agile Framework). Lorsque l’on regarde la situation dans son ensemble, et ce que de nombreuses entreprises font de SAFe, ces préoccupations sont recevables et devraient être prises au sérieux. Pourtant, aucune de ces préoccupations ne pourrait être résolue par un consultant SAFe compétent (SAFe® Practice Consultant-T – SPCT) et une direction soucieuse de réaliser une différence significative dans ses méthodes de travail. Dans cet article, je considère certaines de ces préoccupations. Michael Küsters.

Préoccupations typiques avec SAFe

Avant de creuser, je crois que les compétences et l’expérience de vos consultants SAFe sont essentielles au succès de SAFe. Si vous comptez sur des gens qui ne comprennent pas les conséquences des conseils qu’ils donnent, vous êtes dans une situation difficile. Un de mes amis SPCT (SAFe® Practice Consultant-T – SPCT) a récemment déclaré :

Avoir les mauvais SPC (SAFe® Practice Consultant) – ou ignorer complètement les conseils d’un SPC – vous coûtera facilement dix fois plus cher que ce qu’un bon SPC vous coûterait.

Je suis d’accord. Les bons SPC valent leur pesant d’or. Malheureusement, ils ne poussent pas sur les arbres… Mais c’est une autre histoire. Maintenant, jetons un coup d’œil à certaines des préoccupations que je rencontre habituellement, et ce que vous devez considérer.

SAFe répond à l’état d’esprit traditionnel

SAFe reconnaît et respecte que de nombreuses organisations en transition vers des pratiques agiles ont encore un état d’esprit traditionnel. Par conséquent, beaucoup de matériel dans SAFe est écrit d’une manière qui pourrait être plus acceptable pour les personnes qui ont une faible compréhension de l’agilité. C’est l’idée de « rencontrer les gens là où ils sont ». Oui, c’est controversé, mais c’est de loin mieux que d’affronter les personnes mêmes dont vous avez besoin pour réussir un changement. Ce qui se passe après les avoir rencontrés dépend beaucoup de leur motivation à changer et de la capacité du SPC à mener le changement.

Complexité excessive

Tout d’abord, si vous n’avez pas les problèmes que SAFe adresse, ne l’utilisez pas. Ceci étant dit, SAFe ne peut pas et ne devrait généralement pas être appliqué dans son intégralité. Au contraire, lorsque vous repérez un problème pour lequel SAFe propose une solution, vous pouvez regarder ce que dit SAFe, avoir une discussion pour savoir si cela vaut la peine d’essayer. Et, si c’est le cas, alors allez-y.

Visitez le site SAFe

Cela ne signifie pas non plus que vous devez faire des choses qui adressent des problèmes que vous n’avez pas, ni que vous devez faire les choses comme SAFe dit de le faire si cela ne fonctionne pas pour vous. Pour ma part, quand quelqu’un vient me voir et me dit : « Nous utilisons SAFe et avons tel ou tel problème », je me réfère généralement à un article SAFe, et les pointeurs originaux auxquels SAFe fait référence, et je prends la discussion à partir de là. Pour moi, SAFe est un déclencheur de discussion, pas la panacée à tous les maux.

Des dépendances partout !

SAFe reconnaît que les dépendances peuvent être un défi dans les organisations complexes. Il fournit des conseils et des pratiques clairs qui rendent les dépendances visibles, puis offre un moyen de traiter ces dépendances de manière systématique. Dans de nombreuses organisations, les dépendances sont inévitables mais au moins vous savez quels problèmes vous avez à cause d’elles, et vous pouvez commencer la discussion sur ce qu’il faut faire à leur sujet. J’ai vu plus d’une fois que les équipes trouvaient leurs dépendances irréalisables et décidaient de se réorganiser. Une excellente discussion à avoir.

Durée des intervalles de planification

SAFe utilise une approche de planification basée sur un cadencement avec des intervalles de planification (Planning Intervals – PIs) de longueur fixe s’étendant généralement sur 8 à 12 semaines. Des intervalles de planification plus longs offrent stabilité et prévisibilité aux équipes au détriment de la flexibilité. Cependant, vous pouvez ajuster la durée des PIs en fonction de votre propre contexte. J’ai vu des trains de livraison agiles exécuter 3 sprints de 1 semaine plus un sprint PI de 1 semaine. Cela correspond même au vieux slogan de Scrum, « Working Software in 30 days or less » – à grande échelle ! Essayez ce qui fonctionne pour vous et discutez.

Processus de planification descendants

Peut-être avons-nous une mauvaise image dans notre tête, mais qui peut nous en blâmer quand nous avons été conditionnés à penser en hiérarchies ? Dans un contexte SAFe, vous aimeriez décentraliser ce qui a du sens mais tout n’a pas de sens à être décentralisé. Par exemple, la fonction de Product Management dans SAFe pourrait être composée de Product Owners par équipe, s’ils ont les compétences et la capacité de réussir dans ce rôle, de sorte que cela n’a pas besoin d’être hiérarchique.

Ce dont vous avez besoin, c’est de vous concentrer clairement sur les plus gros morceaux de valeur et d’aligner toutes les équipes autour d’eux.

La façon dont cela se produit peut varier d’une organisation à l’autre, mais le fait que chaque équipe décide par elle-même n’augure rien de bon. Veuillez noter que SAFe encourage la participation active et l’autonomisation des équipes et des individus dans la prise de décisions.

Pas de vrai Scrum

Guide téléchargeable gratuitement

SAFe n’est pas une implémentation stricte de Scrum, mais plutôt un cadre qui intègre des principes et des pratiques agiles provenant de diverses sources, y compris Scrum. Étant donné que de nombreuses équipes utilisent déjà Scrum et sont familières avec les concepts de base de Scrum, SAFe en a tiré parti et conserve les principes fondamentaux de transparence, d’inspection et d’adaptation.

Lorsque je coache des équipes SAFe, je me réfère souvent au Guide Scrum et suggère que comprendre et pratiquer Scrum aide beaucoup à bien mettre à l’échelle. Malheureusement, ce que je vois assez souvent, c’est que les organisations ont déjà utilisé un Scrum hautement dysfonctionnel depuis des années, et veulent maintenant changer cela. En fait, la transformation SAFe pourrait être l’occasion de réparer les trucs Scrum qui ont toujours été cassés et n’ont jamais été résolus.

Les équipes deviennent des usines à fonctionnalités (Feature Factories)

C’est déjà un dysfonctionnement parce que les fonctionnalités produites avec SAFe devraient se concentrer sur la valeur, pas sur la maximisation de la quantité de travail livré. Vous ne devriez avoir qu’un seul ART Kanban hiérarchisé par valeur et les équipes devraient collaborer sur des objectifs partagés, en utilisant des backlogs communs et des événements inter-équipes pour assurer une solution système cohérente qui maximise la valeur.

Lisez cet article en anglais.

Alors que parfois, je constate que les équipes individuelles peuvent se concentrer sur la fourniture de leurs propres fonctionnalités indépendamment de la valeur.

SAFe fournit des mécanismes tels que les démonstrations système et les événements d’inspection et d’adaptation pour s’assurer que les équipes ne partent pas sur une tangente et effectuent une grande quantité de travail de faible valeur.

Processus d’estimation fallacieux

Il y a beaucoup à dire sur le processus d’estimation de SAFe, et j’ai ma propre opinion sur les conseils donnés. Pour faire simple: Ces conseils sont réservés aux personnes qui ne savent pas par où commencer. Le coaching et l’empirisme devraient conduire à une approche qui répond aux besoins de ceux qui ont besoin des estimations.

Vous devez réaliser que dans les grandes organisations, très souvent, plusieurs parties prenantes, d’autres équipes et potentiellement de grosses sommes d’argent dépendent de l’établissement de prévisions assez précises de l’achèvement. L’estimation peut avoir des implications qui n’existent pas dans des contextes plus petits.

Mon propre exemple est que nous devons absolument savoir si la fonctionnalité sera prête pour un salon précis ou si nous devons mitiger. Mais « Eh bien, nous pourrions ou être prêts à temps ou pas pour le salon » pourrait conduire à un désastre majeur en matière de relations publiques, et est probablement inacceptable.

Un événement d’amélioration continue tous les 3 mois, c’est trop peu, trop tard

Alors que l’événement Inspect and Adapt (I+A) se produit à la fin de chaque intervalle de planification (PI), SAFe encourage l’amélioration continue tout au long du PI, les Scrum-of-Scrums (SoS) et les rétrospectives étant des opportunités pour faire apparaître et résoudre les problèmes transversaux.

J’ai moi-même donné des conseils sur le fait que les équipes sont censées apporter leurs propres changements et améliorations indépendamment de l’événement I+A, et même partager leurs apprentissages avec d’autres équipes pendant cet événement. Je m’attends à ce que les équipes apportent des problèmes à court terme au SoS, et n’apportent à l’I+A que des problèmes qui nécessitent des périodes de préparation et d’observation plus longues, et ont un impact bien au-delà des limites de l’équipe. Surtout, vous devez considérer que le I+A est un point de réflexion, où vous vous détachez de la routine quotidienne et vous réunissez en tant qu’équipe d’équipes pour discuter des choses dont vous devez discuter et dont vous n’avez jamais eu l’occasion de discuter auparavant. Il y a toujours quelque chose. Oui, vous pourriez avoir de tels événements plus souvent si vous pensez que cela pourrait aider, il n’y a rien dans SAFe qui vous arrête. Essayez.

Conclusion

Je conviens que le Scaled Agile Framework (SAFe) a des domaines d’interprétation et suscite des préoccupations. S’attendre à ce que ce soit une solution miracle est complètement irréaliste. SAFe fournit une approche structurée pour les grandes organisations qui essaient de donner un sens à toute cette chose « Agile », mais cela ne fonctionne que si elles ont quelqu’un qui comprend plus que ce que dit le matériel. Lorsque vous pouvez faire face aux complexités du développement à grande échelle, de la collaboration entre les équipes et de l’alignement global tout en vous améliorant continuellement, vous avez réussi avec SAFe.

Pour y arriver, vous devez absolument personnaliser SAFe et l’utiliser à bon escient sinon cela deviendra un gâchis, et c’est pourquoi vous avez besoin de personnes qui savent de quoi elles parlent.

Et j’ai vu ce gâchis : La pagaille prend des années à nettoyer. Les personnes qui soutiennent votre initiative de changement doivent être en mesure de répondre aux préoccupations critiques en fonction de leur propre expérience et de leurs apprentissages. Et les personnes de votre organisation qui ont des préoccupations ont besoin d’un temps et d’un endroit où exprimer ces préoccupations car ce n’est qu’alors que vous pourrez vraiment vous améliorer.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Les avantages des lignes de référence de base dans le management de projets.

De nombreux managers de projet travaillent dur pour établir un échéancier précis, puis omettent la dernière étape de la sauvegarde d’une base de références !

The Benefits of Baselines par Bonnie Biafore

https://www.bonniebiafore.com/the-benefits-of-baselines/

Visitez le site de Yookkan, notre partenaire.

De nombreux managers de projet travaillent dur pour établir un échéancier précis, puis omettent la dernière étape de la sauvegarde d’une base de références ! Un échéancier de référence offre tellement de bénéfices que vous ne voulez pas manquer.

Voici quelques avantages clés des bases de référence de planification.

Suivez votre projet par rapport au plan d’origine.

Les managers de projet expérimentés savent qu’aucun plan ne survit au contact de la réalité ! Pour obtenir le statut de projet automatisé, vous devez utiliser un outil de planification (tel que MS Project, Primavera et autres). Et ces outils ont besoin d’une base de référence avant de pouvoir fournir des rapports comparant les progrès réels et les coûts à votre plan initial. Les chiffres réels comparés à la base de référence peuvent ensuite être utilisés pour prévoir les délais et les coûts à l’avenir.

Améliorez votre estimation.

Relisez ce billet sur le cône d’incertitude des estimations.

Les échéanciers de référence aident à montrer quand les chiffres réels divergent du plan d’origine. Voir les écarts par rapport au plan peut vous aider à améliorer les estimations. Les estimateurs obtiennent des retours sur l’exactitude de leurs estimations. Sans cette rétroaction, les estimations ne s’amélioreront pas. Supposons que vous demandiez à quelqu’un d’estimer une tâche et qu’il vous dise que cela prendra deux semaines. Cela prend finalement quatre semaines. Si la personne n’entend jamais parler de cet écart, elle annoncera quand même deux semaines la prochaine fois, alors que la tâche en prendra probablement à nouveau quatre.

Renforcez la responsabilisation auprès des membres de l’équipe et de la direction.

Le partage d’un échéancier de référence renforce les efforts et le temps que les membres de l’équipe ont consacré à votre projet. Il en va de même pour le management. Cela contribue à renforcer l’engagement de la direction à donner du personnel au projet. À mesure que les priorités opérationnelles changent, le temps disponible du personnel du projet peut également changer. Vous pouvez comparer les affectations prévues de base en personnel au temps réel passé pour montrer pourquoi un projet est en retard.

Gérez les seuils.

Relisez la partie de ce billet sur le « statut pastèque »: Vert à l’extérieur mais rouge dedans.

Les rapports sur l’état d’avancement des projets utilisent souvent des indicateurs de feux de signalisation. Le vert signifie que tout va bien. Le jaune indique un problème passager. Et le rouge signifie qu’il y a de sérieux problèmes. Ces couleurs indiquent généralement un niveau d’écart par rapport au plan. Par exemple, 0 à 2 % de dépassement des délais peut être vert. 2-5% au-dessus est jaune. Et plus de 5% de dépassement des échéances est rouge. Le suivi des chiffres réels par rapport au plan de référence constitue la base de ces variations.

Facilitez la planification des programmes.

Quand vous managez un programme, un livrable d’un projet peut être le prédécesseur d’une tâche sur un autre projet. Dans ce cas, il est essentiel de comprendre quand les tâches seront terminées.

Projet ou Programme ? Découvrez ou relisez ce billet.

Un échéancier de référence ainsi que des dates d’achèvement des tâches réelles mises à jour vous aident à comprendre comment les performances d’un projet affecteront un autre projet dans votre programme.

De quelles autres façons utilisez-vous les bases de référence pour améliorer les performances des projets ?

Pour en savoir plus sur les bases de référence des horaires, consultez le cours de Bonnie Project Management Foundations: Schedules.

Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées

Comment évaluer une grosse demande de modification de projet

Quelles questions se poser pour bien instruire une demande de modification majeure qui va impacter coûts, délais et qualité de votre projet ?

How to evaluate a large project change request par Bonnie Biafore

http://www.bonniebiafore.com/how-to-evaluate-a-large-project-change-request/

Les demandes de modification de projet sont monnaie courante. Parfois, une demande de modification peut être volumineuse et nécessiter une analyse supplémentaire. Voici les questions à poser pour fournir au comité de revue des demandes de modifications les informations dont il a besoin pour prendre une décision sur une demande de modification majeure.

Le changement augmentera-t-il la complexité du projet ?

Les organisations disposent souvent d’un ensemble standard de paramètres pour évaluer un changement de projet. Le coût, la portée, l’échéancier et la qualité sont les plus usuels. Très peu d’organisations évaluent l’impact en matière de complexité.

Le nombre d’intervenants, la technologie requise, l’utilisation d’outils innovants et d’autres éléments contribuent à la complexité.

Une complexité accrue peut augmenter les risques, les coûts et nécessiter des ressources supplémentaires.

Le changement pourrait-il accroître les tensions entre les principales parties prenantes ?

Évaluez les changements apportés au projet pour déterminer s’ils augmenteront la tension entre les intervenants.

Par exemple, les changements qui augmentent la tension comprennent :

  • Problèmes de priorisation : Lorsque différents secteurs de l’entreprise attribuent des priorités différentes à l’utilisation des fonds et des délais.
  • Conflits de processus : Quand un changement de processus profite à un secteur de l’entreprise et augmente la charge d’un autre. Par exemple, l’automatisation du traitement du remboursement des frais de déplacement peut faciliter le travail des ressources humaines, tout en créant des problèmes pour le département finances.

Y a-t-il des différences de fuseaux horaires et d’attentes ?

Si de nouvelles parties prenantes se trouvent dans des fuseaux horaires ou des pays différents, répondre aux questions et examiner les livrables peut prendre plus de temps. De plus, les intervenants qui comptent déjà sur un échéancier précis pourraient être mécontents du retard. De surcroît, les livrables peuvent être plus complexes lorsque les exigences d’autres pays sont intégrées à la solution.

Les risques ont-ils un impact sur les contraintes inamovibles ?

De nombreux projets ont des contraintes dures, des conditions qui ne peuvent pas être compromises. Par exemple, un projet visant à apporter des modifications pour se conformer à une nouvelle loi doit se terminer avant que la loi n’entre en vigueur. Un autre exemple est que vous devez ajouter certaines fonctionnalités à votre produit pour devancer vos concurrents.

Tout changement qui met en péril une contrainte stricte doit être examiné avant d’être approuvé.

Le sponsor appuie-t-il le changement (en privé) ?

Un sponsor peut exprimer son soutien à un changement dans un cadre public en raison de réalités hiérarchiques ou politiques. Il peut partager ses préoccupations avec vous en privé. Votre analyse de changement devrait creuser ses préoccupations privées. Cette conversation avec votre sponsor peut également être utile en aval si le changement est approuvé car vous connaissez les impacts à surveiller pour tenir votre sponsor informé.

Quelle analyse supplémentaire effectuez-vous pour les demandes de modification importantes ?
Les traitez-vous différemment ?
Si oui, partagez-le avec nous dans la section commentaires.

Pour en savoir plus sur les changements de projet, consultez le cours de Bonnie sur Project Management Foundations.

Pour une priorisation Agile optimale, concentrez-vous sur les bénéfices !

Pour de nombreux professionnels de projet, la gestion d’un arriéré dhistoires utilisateurs dans un projet agile peut se faire sans nécessiter de profonde réflexion. Mais qu’est-ce qui détermine la priorité et comment cela contribue-t-il à produire les bénéfices escomptés ?

Prioritisation in Agile: Focus on the Benefits par Quay Consulting

https://www.quayconsulting.com.au/news/prioritisation-in-agile-focus-on-the-benefits/

L’un des principes clés de la livraison de projet agile est la flexibilité de permettre une approche plus itérative et acceptant le changement en ce qui concerne le contenu, garantissant que les éléments les plus à valeur ajoutée sont livrés en premier.

Ce n’est pas une approche exempte de contraintes, loin s’en faut. Les équipes de projet agiles adoptent une vision stricte du temps et des coûts, appelée time-boxing, et reconnaissent que les limites de ressources et de temps permettent à l’équipe de se concentrer sur la répartition et la priorisation du contenu pour s’assurer qu’un bénéfice est livré.

Relisez ce billet

Le rôle du propriétaire du projet est essentiel à la réussite, compte tenu des responsabilités qu’il assume dans la définition, la hiérarchisation et l’approbation ou le rejet du travail fourni par l’équipe. Faire un « bon travail » est rarement suffisant pour garantir un bon résultat, et le rôle que joue le propriétaire du produit est très difficile à bien faire.

Lorsque les processus agiles sont bien suivis et selon des normes élevées et alignées, une approche agile peut maximiser le potentiel de retour sur investissement et offrir les bénéfices recherchés par un projet. Lorsque ces processus sont moins bien exécutés, le risque de ne fournir aucune valeur est très réel.

Alors, quels sont les défis qu’un propriétaire de projet peut rencontrer et comment mettent-ils les avantages en péril ?

Contraintes de priorisation

Le time-boxing est une technique qui permet à un projet de disposer de ressources limitées pour fournir la liste de la portée souhaitée. Il est courant de démarrer un projet avec plus de portée qu’il n’y a de financement pour la réaliser, et même si cela ne commence pas avec cela comme défi initial, l’opportunité créée en construisant de plus petits morceaux de contenus dans les itérations permet à l’équipe d’identifier de nouveaux éléments avec des bénéfices potentiellement plus importants.

Le diagramme illustre l’incidence des contraintes sur l’arriéré de produit lorsqu’une ligne est tracée entre ce qui est prioritaire et qui entre dans l’enveloppe de financement et ce qui n’est pas prioritaire ou pas financé.

Le propriétaire du produit est responsable de la priorisation, en pratique, de décider ce qui est au-dessus ou au-dessous de la ligne. La capacité de prendre les bonnes décisions en matière de priorisation nécessite une compréhension approfondie des besoins, des préférences et des points faibles des clients, ainsi que des buts et objectifs de l’entreprise. Cela nécessite également d’avoir une vision claire du produit.

Mais comment prennent-ils les décisions concernant ce qu’il faut promouvoir et ce qu’il faut dé-prioriser ?

Facteurs de priorisation

Qu’un projet utilise l’agilité ou non, de nombreux facteurs doivent être pris en compte lorsqu’un propriétaire de produit choisit ce qu’il faut prioriser et ce qu’il ne faut pas prioriser.

Par exemple :

  • Impact utilisateur : Réfléchissez à l’impact de l’histoire utilisateur sur l’expérience de l’utilisateur final. Cela améliorera-t-il leur expérience ou résoudra-t-il un problème important ?
  • Complexité : Tenez compte de la complexité de l’histoire utilisateur. Est-ce une tâche simple, ou cela nécessite-t-il beaucoup d’efforts et de ressources de développement ? Ce facteur est plus utile lorsqu’il est considéré en conjonction avec la valeur business.
  • Dépendances : Tenez compte des dépendances de cette histoire utilisateur vis-à-vis d’autres histoires ou fonctionnalités. Sera-t-il plus facile de terminer cette histoire avant ou après une autre ? Cette histoire est-elle nécessaire dans le cadre d’un ensemble pour offrir une expérience significative ?
  • Risque : Tenez compte du niveau de risque associé à l’histoire utilisateur. Implique-t-elle des risques techniques ou business qui pourraient avoir une incidence sur la réussite du projet ? Y a-t-il des risques de remaniement ou d’utilisation excessive de temps et de ressources qui, si cela se produisait, diminuerait la valeur de l’histoire ?
  • Temps et coût : Tenez compte du temps et du coût nécessaires pour compléter l’histoire utilisateur. Peut-elle être achevée dans les délais et le budget impartis, et offre-t-elle un retour sur investissement significatif ?
  • Valeur business : Tenez compte de la valeur commerciale de l’histoire utilisateur. Apporte-t-elle une valeur significative au client ou à l’utilisateur final ? Répond-elle à un besoin ou à un problème critique ? Est-ce que le fait de la terminer rapproche le projet de son objectif ?

Comme la portée est divisée en de nombreux petits éléments de contenu dans les projets agiles, il peut devenir très difficile de déterminer dans quelle mesure chaque élément contribue aux bénéfices globaux que le projet cherche finalement à produire.

Le processus de priorisation et le contexte

Il existe une théorie autour du changement qui sous-tend un projet, y compris les projets agiles.  Les bénéfices sont un résultat positif obtenu en fournissant le contenu souhaité.

Il y a un peu plus…

Généralement, un projet commence par des buts et des objectifs, qui sont traduits en portée et livrables.  La relation entre les facteurs et le contexte fourni par les buts et objectifs du projet sont des ingrédients importants dans le processus de priorisation car ils aident à donner plus de sens à chaque histoire utilisateur.

Considérons ce que chaque composant représente :

  • Objectifs : Décrivez les résultats ou les avantages de haut niveau que le projet vise à atteindre ou à impacter; par exemple, un projet vise à améliorer l’expérience client globale de 10 %.
  • Cibles : Cibles précises, mesurables et limitées dans le temps qui doivent être atteintes pour atteindre les buts du projet. Elles sont souvent décomposées en étapes plus petites et réalisables. Par exemple, si l’objectif du projet est d’améliorer l’expérience de 10%, une cible pourrait être d’améliorer la vitesse de traitement des commandes et leur précision afin de réduire les plaintes des clients de 25%.
  • Portée : Établit les limites de ce que le projet inclura ou exclura. Elle définit les caractéristiques, les fonctions et les tâches qui feront partie du projet. Par exemple, la portée d’un projet de développement de site Web pourrait inclure la conception et la construction d’un site Web, mais exclure la création de matériel de marketing.
  • Livrables : Livrables ou résultats tangibles et mesurables qui sont produits à la suite de l’achèvement des travaux du projet. Les livrables peuvent être des produits, des services, des documents ou des rapports. Par exemple, les produits livrables du projet de développement de sites Web pourraient inclure un site Web fonctionnel, des formulaires clients, des articles de connaissances connexes et des services de chat.

Il existe de nombreuses considérations qu’un propriétaire de projet doit prendre en compte lorsqu’il décide de l’arriéré de produit d’un projet agile et celles-ci doivent être faites dans le contexte des buts et de la définition objective du projet. Ceci devrait permettre au propriétaire du projet de peser le mérite de chaque facteur et de déterminer la valeur de chaque histoire utilisateur et comment elle contribue aux bénéfices.

Maintenir un focus laser sur les bénéfices et le retour sur investissement

Les Product Owners doivent solliciter les commentaires, les retours et la collaboration des parties prenantes pour mieux comprendre l’impact ou les conséquences potentiels de la façon dont ils priorisent les histoires utilisateur ou les groupes d’histoires. Cela peut également fournir une perspective sur la complexité ou le coût de leur mise en œuvre et donner un aperçu du point de vue ou de la compréhension des parties prenantes de ce qui est attendu en termes de retour sur investissement.

La nature interdépendante de ces éléments démontre qu’il n’y a jamais de processus linéaire ou simple dans la hiérarchisation des priorités; Les histoires utilisateur et la façon dont elles sont priorisées ne peuvent pas être prises isolément sans effet sur les résultats. Des composants à valeur ajoutée pourraient être livrés, mais pas fusionnés dans une solution cohérente.

Il est essentiel que les propriétaires de produits soient en mesure de se concentrer sur les bénéfices et le retour sur investissement dans la façon dont ils prennent des décisions sur comment ils décomposent le contenu et décident quelles histoires d’utilisateurs sont incluses ou dé-priorisées.

Plusieurs vidéos intéressantes sur Scrum en langue anglaise

Je vous propose de commencer par Scrum.Org avant de zoomer sur les valeurs de Scrum, le Sprint Planning et les Sprint Reviews.

Ces vidéos peuvent s’avérer très utile pour sensibiliser votre comité de projet, votre sponsor et autres parties prenantes à ce qu’est Scrum avec ses valeurs ainsi que certaines de ses « cérémonies » les plus utiles.

Dans cette vidéo de 2 minutes, apprenez-en davantage sur ce que Scrum.org est et fait.

Voici quelques exemples de comment appliquer les valeurs Scrum de courage, engagement, focus, ouverture et respect.

Comment faciliter le Sprint Planning ?

Dans cette vidéo introductive, comprenez comment et quand utiliser certaines techniques de facilitation comme le vote romain, la visualisation et le questionnement afin que votre équipe puisse quitter la session de planification du sprint avec un objectif de sprint en direction de l’objectif du produit et un plan initial pour le sprint.

Comment faciliter les primordiales sessions de Sprint Review ?

Voici au moins une technique de facilitation qui va vous aider à transformer la revue de sprint en une session plus engageante et collaborative. Vous pourrez alors y recueillir des commentaires précieux des parties prenantes pour déterminer les futures adaptations de votre approche et de votre produit.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Pas de surprises : Pourquoi les stratégies d’exécution sont-elles essentielles à la réussite du projet ?

Le vieil adage selon lequel ne pas planifier est un plan pour échouer est approprié dans la réalisation de projets.

No Surprises: Why Execution Strategies are Critical for Project Success par Quay Consulting

https://www.quayconsulting.com.au/news/no-surprises-why-execution-strategies-are-critical-for-project-success/

Ne pas planifier, c’est échouer, dit le vieil adage.

Comme les projets nécessitent de nombreux artefacts au lancement d’un projet, une stratégie qui manque souvent est celle d’exécution qui pourrait faire ou défaire votre capacité à réussir.

Tout praticien de projet chevronné connaît bien la charge documentaire qui accompagne l’établissement et l’exécution de projets : plans de gestion de projet, chartes de projet, échéanciers, plans de ressources et bien d’autres.

Le vieil adage selon lequel ne pas planifier est un plan pour échouer est approprié dans la réalisation de projets, car il existe de nombreux chemins à évaluer pour résoudre un problème d’entreprise et il est rare d’en définir un seul qui mènera à des résultats positifs.

Cependant, l’un des facteurs les plus précieux pour naviguer dans ces chemins est la définition d’une stratégie d’exécution, qui fournit l’approche stratégique de haut niveau qui montre comment un projet pourrait atteindre ses objectifs.

Considérez votre mode de transport métaphorique

Une stratégie d’exécution, c’est un peu comme planifier un voyage. Il existe de nombreux modes de transport qui vous aideront à atteindre votre destination : une voiture, un avion, un bateau, un voyage organisé, ou dans certains cas plus obscurs, il peut être multimodal. Il y a des facteurs qui vont influencer la façon dont vous choisissez de vous y rendre, comme si vous voyagez en groupe, les besoins et les préférences de chacun doivent être pris en compte, combien de temps vous avez et le budget disponible… Ces facteurs influencent tous les décisions que vous devez prendre.

Chaque point de décision présentera des avantages et des inconvénients et vous devrez considérer ce qui vous aidera à y parvenir en fonction de vos propres objectifs pour votre voyage. Si la vitesse jusqu’à destination est primordiale, peut-être que la réservation d’un billet sur le prochain vol commercial est une approche intelligente, allez-y confortablement avec les ressources que vous pouvez transporter et aussi rapidement que possible.  Peut-être que la voiture est une meilleure solution car vous pouvez transporter plus de matériel avec des barres de toit et des remorques pour avoir tout le kit nécessaire pour l’aventure. Cela peut prendre plus de temps mais être une solution plus rentable.

Il y a tous les éléments – temps, rapidité, coût – qui influencent l’exécution dans les projets et ils sont pertinents dans ce qu’une bonne stratégie d’exécution doit prendre en compte, par exemple:

  • Les besoins et les attentes des parties prenantes;
  • Le but, les objectifs et les avantages qui influencent les décisions que vous devez prendre;
  • la portée, les ressources et les dépendances du projet; et
  • Les risques associés et les considérations de changement.
Une stratégie d’exécution bien définie fournira les éléments qui soutiennent la réussite d’un projet
  1. Elle alignera les parties prenantes et les membres du comité de projet autour d’une approche unique qu’ils conviennent/jugent être la meilleure voie à suivre pour réaliser le projet et en récolter les bénéfices.
  2. Elle fournira à l’équipe de projet un cadre pour la planification détaillée, le dimensionnement et la priorisation afin d’avancer.

Décomposons-les davantage.

Alignez vos parties prenantes

Un bateau prend de la vitesse lorsque tout le monde rame dans la même direction :  c’est le pouvoir d’aligner les parties prenantes, les sponsors et l’équipe de projet autour d’une stratégie d’exécution.

Toutes les personnes impliquées sont sur la même longueur d’onde au sujet de l’ordre des travaux et des priorités du projet, du moment où les ressources ou le support doivent être utilisés et de la façon de résoudre les désaccords dans le projet. La stratégie d’exécution aura débattu et finalisé ces considérations avant que le projet ne soit en cours d’exécution et ne devienne très coûteux à retravailler.

Dans son état initial, une stratégie d’exécution est un peu comme un document d’options dans lequel chaque option pour le projet a un profil de coût, un profil de risque, un profil de bénéfices et d’autres avantages et inconvénients. Il y aura généralement une sorte d’échelle qui illustre comment les approches plus agressives apportent des avantages mais comportent plus de risques ou les approches plus conservatrices permettent de livrer des éléments utilisables plus petits qui permettent de tirer des leçons avant de passer à la vitesse supérieure. Ces dernières peuvent prendre plus de temps à compléter, mais être plus diligentes sur le coût.

C’est une opportunité importante de convenir d’une route à suivre avant que les défis inévitables ne surviennent dans le projet et un moyen précieux d’atténuer les dérapages du projet.

Débloquez à la fois la planification et la progression

Les équipes de projet peuvent s’enliser dans une planification de projet détaillée, en essayant de présenter un échéancier de projet réalisable et à mesure que diverses équipes et ressources se réunissent avec leurs propres points de vue, l’approche ascendante peut devenir un peu comme d’essayer de faire bouillir l’océan.

Une stratégie d’exécution peut vous sortir de l’impasse des défis de planification en appliquant des principes directeurs qui permettent aux équipes de réaliser des percées dans la planification, la répartition des tâches et de progresser rapidement. Elle fournit le cadre de travail au sein duquel souvent les équipes peuvent avancer plus efficacement et trouver les meilleurs moyens de fonctionner.

Naturellement, pour réussir, la stratégie d’exécution ne peut être séparée d’aucune réalité pratique. Elle doit prendre en compte les capacités et les contraintes des équipes et leur permettre d’élaborer un plan dont elles peuvent être sûres qu’il est réalisable et répond aux attentes. Cela leur fournit également une compréhension claire de ce à quoi « bien » ressemble et aide à identifier rapidement si quelque chose n’est pas réalisable afin qu’il puisse être adressé rapidement et efficacement.

Application d’une stratégie d’exécution

Une stratégie d’exécution n’a pas besoin d’être son propre document. Il peut s’agir d’un jeu de transparents dans une présentation en comité de projet ou d’un document sur les options possibles. Ce qui est important, c’est que le débat ait lieu et qu’un consensus soit atteint sur la façon dont le projet sera entrepris.

La plupart des stratégies d’exécution se résument à ces 4 approches

Le Big Bang

C’est une approche qui met tout en œuvre, tout en même temps. Elle peut être à haut risque si la mise en œuvre est médiocre car l’impact est considérable.

L’approche phasée

Cette approche divise le projet en phases logiques pour réduire les risques liés à l’achèvement, mettre en avant les bénéfices, contourner les contraintes et adresser les dépendances entre les phases. Par exemple, donner la priorité au développement de l’interface utilisateur digitale dans la première phase et prévoir le développement de l’automatisation des processus en utilisant ces nouveaux parcours utilisateurs numériques dans une phase ultérieure.

L’approche par volet (ou flux de travail)

Cette approche comprend l’exécution indépendante de flux de travail simultanés et connexes pour permettre à chaque volet de se concentrer sur ses livrables et ses échéanciers, sans avoir d’incidence sur les autres avec des retards et une interdépendance.

L’approche échelonnée

Une approche échelonnée est semblable à une approche phasée, mais une approche échelonnée (ou par étapes) est plus alignée verticalement que l’approche phasée qui est alignée horizontalement. Un exemple serait l’élaboration d’un projet pilote pour solliciter des commentaires, puis le déploiement d’un plus grand nombre de fonctionnalités de bout en bout à un plus grand nombre d’utilisateurs.

La stratégie d’exécution évite la plupart des surprises

Les approches ci-dessus ne représentent pas une liste complète des considérations pour l’exécution. La stratégie d’exécution peut aller beaucoup plus loin dans le management du changement et les décisions de mise en service (exécutions parallèles, lancements progressifs, etc.). Cependant, c’est une conversation importante à avoir lors de la conception des cas d’affaire (business case), de la planification de projet à haut niveau et de la rédaction d’une charte de projet.

Les managers de projet n’aiment pas plus les surprises que leurs sponsors ou parties prenantes.

La conversation autour de la stratégie d’exécution permet d’identifier les points de différence d’opinions et de discordes au début du cycle de vie, ce qui permet à l’équipe de projet de gagner du temps pour élaborer un plan réussi et donner aux sponsors la confiance d’une bonne réflexion stratégique.

Quelles sont les techniques d’estimation agiles les plus fréquemment utilisées ?

Il existe plusieurs techniques différentes pour mener le processus d’estimation. Cet article décrit ces techniques, leur pertinence et leur praticité dans les projets Agiles.

Agile Estimation Techniques par David Tzemach

https://www.agilequalitymadeeasy.com/post/agile-estimation-techniques-david-tzemach

Estimations traditionnelles (jours/heures)

Les estimations traditionnelles sont basées sur des unités de jours ou d’heures (dans de rares cas, je l’ai même vu utilisé pour estimer des histoires basées sur 20, 30 et 45 minutes), et l’équipe les utilise pour estimer leurs histoires et leurs tâches. À mon avis, c’est bien si cela aide l’équipe dans le processus de transition et même si elle veut l’adopter comme technique d’estimation. J’espère que vous ne tenez pas compte des récits selon lesquels les estimations traditionnelles ne conviennent pas à Agile car elles sont rarement exactes pour tous ceux d’entre vous qui pensent autrement.

Taille de T-shirt

La taille des t-shirts est une excellente technique d’estimation que j’utilise dans les organisations au début de la transformation. Vous ne pouvez pas utiliser de story points avec certaines équipes, car les membres de l’équipe alignent les story points sur des heures d’effort. Cela conduit à une confusion supplémentaire.

La taille du t-shirt permet aux équipes de surmonter ce problème car cette technique d’estimation n’est pas numérique. Cela permet aux équipes Agile de travailler avec quelque chose de plus facile à comprendre. Cela supprime la précision implicite d’une valeur numérique et libère l’équipe pour penser de manière abstraite à l’effort qu’elle doit investir dans chaque histoire.

Le processus de base de cette technique est relativement simple à utiliser
  1. Un jeu de cartes représentant une taille spécifique est distribué horizontalement sur une table. Les tailles sont divisées en Extra Small (XS), Small (S), Medium (M), Large (L) et Extra Large (XL).
  2. L’équipe ajoute chaque user story sous la carte de taille appropriée.
  3. Une fois que toutes les histoires sont triées sur la base d’une discussion collaborative, l’équipe approuve leur sélection ou conduit un autre cycle de débat sur les histoires qui ont révélé une grande incertitude.

Vote par points (dot voting)

Le vote par points est une autre technique d’estimation relative. Il permet aux équipes Agile de voter leurs préférences parmi un ensemble d’éléments en plaçant simplement des points sur des éléments (par exemple, des fonctionnalités, des histoires, des obstacles, etc.) qui, selon elles, devraient avoir une priorité plus élevée que les autres éléments. Le nombre de points détermine le niveau de priorité. Plus il y a de points, plus la priorité de l’élément est élevée.

Le vote par points est une technique d’estimation très efficace car il permet à tous les membres de l’équipe d’affecter la priorité des éléments de manière égalitaire. Tous les membres de l’équipe ont un nombre égal de votes (représentés par des points), qu’ils peuvent répartir entre les éléments dans le cadre du processus d’estimation.

Par exemple, l’équipe a dressé une liste de huit points lors de la réunion rétrospective. Ils doivent maintenant restreindre la liste aux éléments de valeur la plus élevée. Pour ce faire, chaque membre de l’équipe reçoit un nombre égal de points (entre 3 et 5) pour voter sur les éléments.

Remarque: Ils peuvent mettre tous les points sur un élément ou les répartir entre différents éléments.

Le processus d’utilisation de haut niveau de cette technique d’estimation comprend les phases suivantes
Phase 1 : Facilitation, examen et vote
  1. Tous les articles sont placés dans un endroit accessible pour permettre aux membres de l’équipe de voter.
  2. Tous les éléments sont examinés et compris par toutes les parties prenantes.
  3. Chaque membre de l’équipe reçoit un nombre égal de points (j’utilise généralement cinq points).
  4. Chaque membre de l’équipe est invité à voter. Chacun des membres place des points sur les éléments en fonction de son jugement.
  5. Une fois le processus d’estimation terminé, les articles sont classés du plus fort au plus faible nombre de points.
  6. Approuvez avec l’équipe le résultat du vote.
Phase 2 : Ajustements et nouveau vote (facultatif)

Si l’équipe n’est pas complètement satisfaite du résultat (comme cela arrive souvent…), vous devez suivre les étapes suivantes pour optimiser le résultat :

  1. Organisez les éléments en trois groupes pour représenter les priorités faibles, moyennes et élevées.
  2. Passez en revue avec l’équipe les histoires de chaque groupe.
  3. Lancez un nouveau cycle de vote pour tous les points de priorité la plus élevée.
CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

« Garantir le succès du projet : vers la Project Omniscience » par Cyril Verbrugghe

Cyril Verbrugghe vous propose une approche, la Project Omniscience, pour adapter le management de projet et les défis de planification au monde en perpétuel mouvement dans lequel vous réalisez vos projets.

Près de 65% de vos projets dans l’industrie ne sont pas considérés comme des réussites, du point de vue du respect des délais et de la maîtrise des coûts. Les causes sont nombreuses, et dépendent fortement du contexte du projet, mais l’approche de la gestion et de la planification en sont les principales.

Dans cet article, je vous propose de penser une approche à même d’adapter la gestion de projet et la planification aux enjeux de l’industrie dans son ensemble : la Project Omniscience.

D’ici 2027, la gestion de projets emploiera 88 millions de personnes dans le monde, et la valeur économique des activités orientées projet aura atteint la barre des 20 000 milliards de dollars. En parallèle, les projets industriels actuels, qui travaillent à résoudre des problématiques liées aux enjeux majeurs rencontrés par l’humanité (l’agro-alimentaire, la mobilité, l’énergie, le spatial, …) sont de plus en plus complexes, nécessitant une approche systémique du processus de décision pour assurer leur réussite.

Cette approche est loin d’être généralisée : seuls 35% des projets lancés dans le monde sont couronnés de succès (entendre dans le respect des délais, de la rentabilité, de la qualité des livrables). Ce qui est loin d’être à la hauteur des enjeux : ces échecs entraînent une perte considérable d’argent, d’opportunités et de temps. Or, nous manquons justement de temps…

L’approche systémique du projet : les défis pour une planification consolidée

L’approche systémique du processus de décision et du projet repose sur une prise en compte de l’ensemble des paramètres susceptibles d’influer sur son succès : charges, ressources humaines, matérielles, contraintes d’occupation de site, etc. La planification consolidée est donc en ce sens la pierre angulaire de l’approche systémique du projet.

Or une planification consolidée nécessite de lourds investissements en temps et en argent. La capitalisation du savoir est au mieux hypothétique, et les acteurs de la planification sont contraints pour chaque projet de s’atteler à de la saisie de données (entre autres tâches répétitives). La productivité en est rongée : 1 acteur de la planification sur 4 considère la saisir de donnée comme leur principale source de problèmes, et 54% des chefs de projets dans l’industrie déclarent consacrer un jour par semaine à des tâches fastidieuses qui nécessitent peu ou pas de créativité.

Ainsi, les efforts actuellement nécessaires pour envisager les impacts de scenarii stratégiques sont disproportionnés par rapport à des résultats limités : le coût d’une planification consolidée est trop lourd à porter.

Garantir le succès d’un projet, répondre aux aléas et opportunités (COVID, guerre en Ukraine, innovations disruptives, …) et anticiper dans leur globalité les impacts requiert donc une évolution majeure dans la capacité à capitaliser sur notre savoir et notre expérience issus de précédents projets. Il s’agit de fiabiliser les décisions et sécuriser notre avenir en rendant accessible le savoir industriel projet, pour dépasser la segmentation de la connaissance et les limites intellectuelles à la scénarisation du futur.

Un obstacle à surmonter : la planification « personne-dépendante »

Cette problématique ne reste pas sans réponse : procédures, logiciels de planification 2.0, process mapping, … Toutes ces initiatives visent à améliorer la capitalisation du savoir dans le cadre de la gestion de projet et à consolider le volet de la planification.

Toutefois, peu de technologies peuvent être considérées comme de véritables « outils » au sens littéral du terme, et l’être humain reste le principal vecteur et moteur de la donnée, avec des solutions basées sur les principes Excel.

De ce fait, la bonne sécurisation de nos projets reste « personne-dépendante ». Seuls quelques rares élus ont suffisamment d’expérience pour jongler à la fois avec la connaissance des processus métiers et la technique de planification. Deux ingrédients obligatoires pour nourrir rapidement la stratégie d’un plan clair et exhaustif.

Cette situation génère du stress pour ces experts, dont 41% ont envisagé de quitter la gestion de projet au cours de la dernière année. Elle est également dangereuse pour l’organisation industrielle, car un départ représente des années de connaissance perdues et met en péril la maîtrise des projets.

La Project Omniscience : modéliser le projet grâce à l’IA

Pourtant le monde dans lequel nous entrons nous donne les armes pour adresser cette problématique centrale d’une planification « personne-dépendante », repenser notre gestion de l’information et généraliser l’approche systémique dans la gestion de projet.

Les nouvelles technologies offrent en effet des opportunités d’aller au-delà des limites intellectuelles des êtres humains. Les systèmes intelligents, notamment grâce au deep & machine learning, peuvent stocker et traiter d’énormes quantités de données, et peuvent être utilisés pour aider les chefs de projet à prendre des décisions plus rapidement et plus efficacement.

Ces systèmes intelligents nous ouvrent la porte d’un nouveau monde, celui de la “Project Omniscience”.

Leur puissance de traitement, leur capacité d’apprentissage et les technologies de datavisualisation peuvent permettre de créer un véritable “Jumeau numérique” de votre organisation projet. Une telle modélisation permettrait de simuler instantanément et vérifier les différents scenarii stratégiques, avertir en temps réels sur les signaux faibles, …

Augmenter les leaders projet par la « Project Omniscience ».

Dans ce monde, depuis votre tablette tactile et, en un instant, vous pourrez définir le meilleur moment d’un lancement spatial. Le tout avec précision, en prenant en compte toutes les dimensions nécessaires au succès : occupation du site, capacité de chaque équipe, disponibilité des moyens, budget à disposition.

Dans ce monde, les contraintes business sont intégrées par tous les acteurs du projet ; les décisions commerciales sont optimisées selon les capacités réelles. Un paiement conditionné à un premier livrable ? Vos chefs de projets adoptent immédiatement le meilleur scénario pour livrer les jalons correspondant au plus vite.

Nos projets sont nos meilleurs investissements. Et si la Project Omniscience était moyen le plus sûr de les transformer en actifs financier stables ?

Sources :

  • Harvard Business Review “The Project Economy Has Arrived” – Antonio Nieto-Rodriguez
  • Project Management Institute “2022 Jobs Report”
  • Project Management Institute “AI at work new project new thinking”
  • Gartner “Project Management Technology Trends at the Gartner Program & Portfolio Management Summit”
  • Capterra “Project Management Software Market Research Report”

PMI is a registered mark of Project Management Institute, Inc.


Qui est Cyril Verbrugghe ?

Cyril Verbrugghe

Depuis 2020, Cyril Verbrugghe est Co-Fondateur et PDG d’OFFOLIO. Il travaille actuellement à libérer le potentiel de la planification projet en y apportant Intelligence Artificielle, automatisation et apprentissage.

Double diplômé de l’université Dauphine (Projets & Systèmes d’Information) et de Business School Montpellier (Finance), il a démarré sa carrière en finance de marché. Son parcours en consulting l’a mené sur des missions de déploiement de systèmes d’information, de transformation des organisations puis de stratégie au sein de grands groupes.

Il a ensuite dirigé les activités Europe Moyen Orient Afrique de la technologie Canadienne GlobalTrade Corporation durant 4 années, ou il a œuvré à la transformation digitale de l’écosystème Trade Finance.

Comment faire face à des attentes déraisonnables de certaines parties prenantes dans votre projet ?

Que faites-vous lorsque vous ne pouvez faire changer d’idée des parties prenantes importantes ?

Dealing with Unreasonable Expectations  par Bonnie Biafore

http://www.bonniebiafore.com/dealing-with-unreasonable-expectations/

Les principales parties prenantes exercent parfois une pression importante pour atteindre des objectifs de projet irréalistes. Repousser ces demandes peut mettre sur les nerfs même le/la manager de projet le/la plus expérimenté(e) !

Et il peut être difficile de convaincre ces parties prenantes de changer leurs objectifs ou leurs perspectives. Que faites-vous lorsque vous ne pouvez pas changer l’avis des parties prenantes ?

Adoptez un processus qui vous permettra de gérer les attentes et de faire avancer le projet.

Voici une approche en 4 étapes pour tirer le meilleur parti des attentes déraisonnables.

Étape 1 – Partagez les faits.

Développez un argumentaire simple et direct qui décrit vos préoccupations concernant le projet. Utilisez les données antérieures du projet, les documents de référence de l’industrie et les préoccupations présentées par les leaders techniques. Votre message est susceptible d’être considéré comme une mauvaise nouvelle, alors soyez prêt pour une forte réaction. Cela peut nécessiter plusieurs tentatives pour faire passer votre message, alors soyez persévérant pour faire entendre votre message. Tenez-vous-en aux faits. Ne laissez pas les réactions des parties prenantes détourner votre message en une discussion émotionnelle. Vous partagez des informations sur les risques qui doivent être traités. Gardez à l’esprit que ce n’est pas votre travail d’empêcher les hauts dirigeants de prendre des risques. Votre travail en tant que manager de projet consiste à vous assurer que les parties prenantes reconnaissent les risques que présente le projet. Après votre discussion, traitez les directives que vous recevez du mieux que vous pouvez.

Étape 2 – Comprenez leurs perspectives.

Qu’est-ce qui est réellement important dans le projet pour cette partie prenante ?

Partagez les risques du projet avec un public plus large et écoutez les points de vue supplémentaires de ces parties prenantes. Les membres de l’équipe technique peuvent être surchargés de problèmes ou avoir un volume de travail déraisonnable. Certaines parties prenantes peuvent avoir des intérêts pour leur propre équipe qui entrent en conflit avec la meilleure option pour l’ensemble de l’organisation. Toutes ces choses peuvent finir entre vos mains pour être traitées. Soyez compréhensif et souvenez-vous : Vous ne pouvez aborder les problèmes dans une discussion transparente seulement si les parties prenantes mettent leurs problèmes sur la table. Aidez les autres à comprendre ces perspectives divergentes et générez des discussions pour explorer une chemin plus dégagé pour faire avancer le projet.

Étape 3 – Soyez prêt à faire des compromis.

Ne soyez pas inflexibles. Au fur et à mesure que les conversations que vous organisez se déroulent, certaines de vos tentatives pour réduire les risques du projet peuvent être rejetées. Recherchez une position raisonnable dans le management des risques qui vous permette de faire des progrès positifs vers la réalisation du projet. Le chemin à suivre n’est peut-être pas parfait. Cependant, une amélioration de 80% de votre situation est probablement préférable à une détérioration irrémédiable d’une relation pour atteindre les 90 ou 100%. Lorsque l’environnement pour la livraison du projet n’est pas idéal, mettez en place une surveillance supplémentaire pour remonter les problèmes dès que possible. Discutez de ces sujets de préoccupation avec votre sponsor et lors de vos réunions de projet hebdomadaires.

Étape 4 – Montrez le chemin emprunté par votre projet.

Capitalisez sur votre surveillance pour identifier les problèmes. Créez des mesures qui montrent l’impact des zones de risque sur le projet. Partagez le chemin emprunté par votre projet avec les parties prenantes. Par exemple, si vous craignez que les ressources techniques clés ne soient pas disponibles pour consacrer suffisamment de temps à votre projet, établissez un temps minimum nécessaire pour livrer votre projet dans les délais. Surveillez les heures réelles que votre ressource critique consacre au projet et l’état d’achèvement de ses tâches. Signalez vos résultats lors des réunions d’état d’avancement pour tenir les gens informés de l’état du risque. Si les préoccupations que vous avez soulevées plus tôt (à l’étape 1) ont un impact, vous aurez des données concrètes pour justifier votre préoccupation, et vos parties prenantes seront plus susceptibles d’appuyer les changements dont vous avez besoin pour mener à bien votre projet. Si tout va bien, ne soyez pas complaisant ! Poursuivez la surveillance jusqu’à ce que la possibilité de risque soit éliminée.

Avez-vous des recommandations pour traiter les demandes déraisonnables ? Partagez-les avec nous !

Pour en savoir plus sur la gestion des attentes déraisonnables, consultez la formation Natasha Kasimtseva’s Managing Project Stakeholders course.


Sur la même thématique, relisez ces billets: