DevOps : 3 étapes pour planifier et exécuter un projet réussi

Une préparation diligente, des flux de travail clairement définis et une surveillance vigilante sont essentiels pour livrer un projet DevOps hautement performant. Szymon Piasecki, responsable DevOps chez STX Next.

DevOps: 3 steps to plan and execute a successful project par Szymon Piasecki

https://enterprisersproject.com/article/2023/1/devops-3-steps-plan-execute-successful-project

Bien que DevOps ne soit pas une nouvelle expression ou idée pour quiconque évolue dans l’industrie high-tech, c’est devenu un mot à la mode ces dernières années. Sa popularité est telle qu’il est maintenant crucial de comprendre comment structurer et déployer au mieux une équipe DevOps, et il existe plusieurs points de vue et méthodologies différents sur ce sujet.

En termes simples, DevOps est l’intégration des développeurs et des opérateurs informatiques en un seul groupe, avec l’objectif commun d’améliorer la vitesse et la qualité du déploiement des logiciels. Il a d’abord été créé en réponse aux préoccupations concernant la ségrégation des équipes et la façon dont cela entraînait souvent des ruptures de communication et un manque de cohésion.

Depuis que le terme a été inventé pour la première fois en 1993, DevOps n’a fait que gagner en popularité. 83% des décideurs informatiques en  2021 ont déclaré avoir mis en œuvre ce style de travail sous une forme ou une autre.

Changer l’orientation business de cette manière ne garantit pas un changement immédiat de résultats. Cependant, cette dynamique représente un changement de culture informatique, avec un accent accru sur la collaboration et les compétences relationnelles interpersonnelles. Pour que ce modèle fonctionne à long terme, les ingénieurs doivent être ouverts à cette nouvelle façon de travailler.

Alors, quelles étapes vitales une équipe DevOps doit-elle prendre pour assurer la réussite d’un projet ?

1. Comprendre le pourquoi

Les étapes préliminaires d’un projet DevOps sont cruciales. Sans une direction claire et une compréhension commune au sein de l’équipe, l’initiative est vouée à l’échec.

Pourquoi ce changement ?

L’équipe et le client doivent donc être prêts à consacrer le temps nécessaire pour comprendre les objectifs de chacun et s’assurer que leurs visions s’alignent. Cela peut se faire par le biais de réunions et d’ateliers, où les participants identifient les objectifs et les membres de l’équipe établissent un objectif clair sur ce à quoi le produit final devrait ressembler.

Lorsque cette mise au point est exécutée correctement, l’équipe DevOps quittera la première phase du projet avec un briefing bien défini et une compréhension claire des objectifs du client. Si cette étape est précipitée, les ingénieurs seront gênés par un manque de direction, ce qui augmentera la probabilité que le produit fini ne réponde pas aux exigences du client.

2. Développer

La deuxième phase est celle où le développement de l’application commence. Ceci est généralement facilité par l’utilisation d’une solution basée sur le cloud, où l’équipe commence à préparer l’environnement, à travailler sur les composants qu’il doit contenir et à comprendre comment ils doivent être configurés pour maximiser l’efficacité.

Les meilleures équipes DevOps sont agiles et polyvalentes, avec des membres qui peuvent facilement s’adapter à un nouveau rôle ou aider dans divers domaines.

Pendant cette période, l’équipe doit s’assurer que la version finale de l’application est aussi sécurisée que possible. Pour cette raison, l’équipe DevOps a besoin de compétences diverses, y compris au moins un expert en cybersécurité.

Une phase de développement réussie se caractérise par des flux de travail clairement structurés dans lesquels le projet est décomposé, étape par étape. Tous les membres de l’équipe doivent comprendre où ils s’inscrivent dans le plan et comment ils peuvent contribuer.

Il est important de se rappeler que les projets DevOps sont rarement une promenade de santé du début à la fin. Le développement est souvent entravé par des délais manqués, des bugs et des conflits de priorité qui éloignent les ingénieurs de leurs responsabilités projet. Pour cette raison, les meilleures équipes sont agiles et polyvalentes, avec des membres qui peuvent facilement s’adapter à un nouveau rôle ou aider dans divers domaines. Cette agilité est extrêmement importante pour assurer la continuité lorsque les flux de travail sont perturbés.

3. Tester, surveiller et améliorer

Une fois qu’un produit est mis en ligne, le travail entre dans une nouvelle étape cruciale. Les meilleures équipes DevOps ne se reposent jamais sur leurs lauriers à la fin de la phase de développement. Les développeurs doivent surveiller attentivement l’application à ses débuts afin que tout bug puisse être identifié et immédiatement corrigé.

Des ingénieurs devraient être en place pour surveiller l’environnement, y compris la façon dont il est affecté et comment il réagit aux flux variables de nouveaux utilisateurs. Les données obtenues constituent une ressource précieuse et doivent être traitées comme telles, les équipes triant et étiquetant les résultats dès qu’ils sont collectés.

Une fois les données de référence recueillies, l’équipe doit analyser les résultats pour identifier les parties de l’application qui pourraient nécessiter des améliorations ou une refonte. Après cela, le résultat final devrait être un produit qui fonctionne de manière optimale et répond aux spécifications du client.

Se préparer au succès

Les équipes DevOps qui suivent les étapes décrites ci-dessus auront la certitude absolue que leur projet est sur la bonne voie et qu’il est prêt pour réussir.

Concevoir un produit bien fait est beaucoup plus facile lorsque votre équipe inclut des spécialistes de diverses disciplines qui sont enthousiastes à l’idée de collaborer et de communiquer. Avoir la bonne équipe facilitera également la transition entre chaque étape d’un projet DevOps et garantira que le client est satisfait.

3 idées de planification pour soutenir vos décisions futures

Et si vous optiez pour une planification basée sur les livrables à court terme parce qu’elle concentre tout le monde sur peu de livrables essentiels ?

Par Johanna Rothman, la Pragmatic Manager

De nombreuses organisations utilisent une planification basée sur les livrables, spécifiant les différentes fonctionnalités ou produits que les équipes prévoient de livrer et quand. Je suis fan de la planification basée sur les livrables à court terme parce qu’elle concentre tout le monde sur des (peu et moins nombreux) livrables. La pandémie nous a appris une leçon essentielle : Bien que la planification à long terme basée sur les livrables puisse mettre en lumière les risques, nous ne pouvons pas garantir que nous pourrons réaliser tous ces plans à long terme.

À quand remonte la dernière fois où votre entreprise, votre marché ou votre contexte organisationnel ont changé deux ou trois mois après le moment où vous avez réalisé votre planification ?

Pour de nombreuses organisations, un trimestre (oui, 13 semaines) s’avère être une planification à long terme.

C’est à ce moment-là que mes clients me disent qu’ils se sentent mal à l’aise face à leurs décisions passées. Ils se sont trop engagés et trop à l’avance. Maintenant, le coût d’une re-planification semble élevé.

Vous avez des options.

Au lieu d’une planification à long terme basée sur les livrables, considérez les idées suivantes
  1. Planifiez le moins possible de livrables maintenant, à court terme.
  2. Créez une liste d’options que vous pouvez ajouter, en supposant que vous ayez le temps de terminer plus de livrables avant la prochaine planification.
  3. Définissez les problèmes potentiels, et non les livrables, pour faciliter la prise de décision future.

Voici comment ces idées fonctionnent ensemble.

Idée #1 : Limitez le nombre de livrables à planifier en ce moment

Quelle est l’ampleur et la longueur de votre arriéré de produit (product backlog) actuel ?

Voici quelques lignes directrices que j’ai utilisées pour limiter la planification :

  • Limitez le backlog d’une équipe au nombre d’éléments que l’équipe peut terminer en deux semaines maximum. Parce que même si l’équipe n’utilise pas d’itérations, deux semaines constituent un délai raisonnable pour voir si le backlog doit changer.
  • Limitez votre backlog produit au nombre d’articles que les clients peuvent adopter en environ un mois. Si les clients ne peuvent pas intégrer les changements pour un produit donné plus rapidement, il est peut-être temps de donner un projet ou un produit différent à cette équipe.
  • Limitez le nombre de projets et de programmes au nombre d’équipes. Lorsque les équipes travaillent sur un seul projet ou programme à la fois, elles progressent au maximum de leur capacité. Le multitâche ralentit tout.

Vous pourriez être prêt à m’accorder le bénéfice du doute… Mais qu’advient-il de tout le reste du travail que vous planifiez normalement pour ce projet ou ce produit ?

C’est là qu’une liste d’options aide.

Idées #2 : Créez une liste d’options

Comment montrez-vous actuellement le niveau d’incertitude dans vos plans ? J’aime l’idée de la « big black line* », comme dans Alternatives for Agile and Lean Roadmapping: Part 3, Flow-Based Roadmapping.

Au lieu de vous engager à tout le travail à l’avance, engagez-vous à en faire aussi peu que possible. C’est tout ce qui est au dessus de la ligne. Ensuite, si vous avez le temps avant qu’il ne soit temps de re-planifier, vous pouvez remonter une option située en dessous de la ligne vers le haut.

Vous n’avez pas non plus à classer ces options longtemps à l’avance. Étant donné que personne n’a ces options sur un arriéré de produit ou dans une feuille de route, l’équipe ou le manager de produit peut reclasser les options comme nécessaire. Ou à mesure que le marché, le client et le contexte organisationnel changent.

Les options vous permettent de planifier à long terme, sans vous engager sur ces options.

*big black line: C’est ce dont les équipes ont besoin pour réussir ce trimestre. Compléter tout ce qui est au dessus de cette ligne serait déjà génial. Au fur et à mesure que les équipes terminent les histoires, la communauté projet et le Product Owner réévaluent les histoires restantes sur la feuille de route et sélectionnent lesquelles ajouter au travail en cours.

Idée #3 : Définissez les problèmes pour vos décisions futures

Quand je pense aux arriérés ou backlogs et aux feuilles de route des produits, je pense aux problèmes que nous avons déjà décidé de résoudre. Cependant, j’ai commencé ce billet en suggérant que nous avons besoin de plus de flexibilité dans notre planification parce que notre contexte pourrait changer.

Lorsque nous définissons les problèmes candidats plutôt que les livrables, nous pouvons plus facilement examiner le contexte par rapport à nos plans précédents.

Cela facilite le choix des problèmes à résoudre et du moment où il est possible de s’y attaquer. Et cela permet à tout le monde de raccourcir toutes les boucles de rétroaction lorsque vous gérez votre planification. (Voir Multiple Short Feedback Loops Support Innovation pour plus de détails.)

Soutenez vos décisions futures

Réfléchissez aux livrables que vous souhaitez livrer maintenant et plus tard. Au lieu de pré-spécifier tous ces livrables, lesquels pourriez-vous transformer en options ?

Ensuite, au lieu de vous engager sur des livrables à long terme, pouvez-vous faire de ces problèmes à long terme des idées à adresser ? Plus votre entreprise, votre marché ou votre contexte organisationnel change rapidement, plus vous voudrez peut-être modifier les livrables et le moment pour les livrer. Et vous voudrez peut-être repenser quels sont les problèmes à résoudre et quand.

Votre futur « moi » vous remerciera.

Êtes-vous nouveau avec la newsletter Pragmatic Manager ? Lisez  les numéros précédents.

10 meilleures pratiques de management des réponses aux risques

Votre management des risques doit rester aussi simple que possible et néanmoins vous garantir que les réponses sont faisables, économiquement viables et efficaces.

Inspiré de https://projectriskcoach.com/project-risk-responses/ « 10 Risk Response Mistakes » de Harry Hall.

#1 – Identifiez correctement le propriétaire de chaque risque.

Une fois qu’un risque a été identifié, En tant que manager de projet, vous devez vous demander : « À qui appartient le risque ? ». Le propriétaire de risque est la personne responsable de l’élaboration et de l’exécution du plan de réponse à ce risque.

#2 – Détectez et réagissez aux petits risques connexes.

De nombreux risques sont connectés.

Plusieurs petits risques connexes peuvent avoir un effet boule de neige qui mène éventuellement à un événement important. Apprenez à bien mettre en évidence les connexions entre les risques, comment les percevoir, puis travaillez à les détecter.

#3 – Identifiez et managez les risques secondaires.

Certaines réponses à un risque peuvent déclencher une avalanche d’autres risques.

Lorsque les propriétaires des risques élaborent des plans de réponse à leurs risques, elles ou ils peuvent ne pas tenir compte des risques secondaires. Les risques secondaires sont ceux qui découlent directement de la mise en œuvre d’une réponse au risque primaire. Certaines solutions et plans d’action pour manager un risque pourraient générer d’autres problèmes potentiels.

En tant que manager de projet expérimenté, vous éduquez et demandez à vos propriétaires de risques d’identifier et de planifier les risques secondaires importants.

#4 – Élaborez des plans de contingence.

Certains plans de réponse aux risques doivent être exécutés immédiatement, d’autres sont de ‘contingence’. Ces plans conditionnels ne seront exécutés que si certaines conditions prédéfinies sont remplies.

#5 – Préparez des plans de secours.

Quel est votre plan de secours si celui prévu pour manager le risque échoue ?

Que doit faire un propriétaire de risque si le plan de réponse au risque échoue ?

Elles ou ils devraient mettre en place et être prêts à exécuter un plan de secours pour les risques importants.

Le plan de secours peut être utilisé pour atténuer une menace ou tirer bénéfice d’une opportunité.

#6 – Identifiez clairement les déclencheurs de risque.

Qu’est-ce qui pourrait déclencher ce risque ?

Certains managers de risques font un excellent travail de définition des plans de réponse, mais ne parviennent pas à définir clairement quel serait le déclencheur du risque, comme manquer un jalon.

Aidez-les à travailler ce point.

Les déclencheurs peuvent être utilisés pour avertir que le risque est sur le point de se produire, ce qui donne au propriétaire du risque le temps de mettre en œuvre le plan de réponse à ce risque.

#7 – Sachez saisir les opportunités.

Parmi tous les risques potentiels se cachent aussi des opportunités très positives pour le projet.

Les risques comprennent aussi des événements ou des conditions positives, qui, s’ils se produisent, auront un impact positif sur les objectifs du projet.

Vous serez beaucoup plus efficace si vous parvenez à identifier ces événements positifs et ne ratez aucune chance d’en faire bénéficier votre projet et vos clients

#8 – Tenez à jour vos plans de management de projet.

Vous devez rester synchrone dans l’ensemble de vos plans de projets avec celui de management des risques.

Les plans de management de l’échéancier, des coûts, de la qualité, des approvisionnements, des recrutements et du périmètre. Au fur et à mesure que les propriétaires de risques élaborent des plans de management, vous devez en tant que manager de projet mettre à jour tous ces autres plans en conséquence.

Par exemple vous ajouterez si nécessaire de nouvelles activités au WBS et définirez plus en détail la façon dont les provisions pour éventualités seront utilisées.

#9 – Maintenez un journal des hypothèses.

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

Vous-même et les membres de l’équipe projet faites beaucoup d’hypothèses, en particulier dans les premières phases d’un projet en fonction des informations disponibles. Au fur et à mesure que l’équipe de projet découvre de nouvelles informations, les hypothèses déjà identifiées peuvent nécessiter une mise à jour ou vous pourriez devoir ajouter de nouvelles hypothèses. En gardant ces hypothèses visibles de tous, vous permettez à chacun d’intervenir et de les corriger ou enrichir si nécessaire.

#10 – Créez des contrats ou des accords avec les parties prenantes externes.

Certains propriétaires de risques peuvent souhaiter faire appel à un tiers pour répondre aux risques.

En tant que manager de projet, vous allez vous assurer que ces décisions et contrats soient documentés et approuvés si besoin.

Voyez-vous d’autres mesures à prendre pour mieux pour planifier la réponse aux risques ?

Envisagez d’utiliser cette liste comme une simple liste de contrôle et appliquez-la sur l’un de vos projets actuels pour la tester.

Votre management des risques doit rester aussi simple que possible et néanmoins vous garantir que les réponses sont faisables, économiquement viables et efficaces.

Les avantages de la pensée systémique dans le management de projets

Perspectives PMBoK7 : Pensée systémique par Bonnie Biafore

http://www.bonniebiafore.com/pmbok7-perspectives-systems-thinking/

Le PMBOK V7 sur Amazon

Le Project Management Body of Knowledge® (PMBoK7) parle de reconnaître, d’évaluer et de répondre aux interactions du système, ce qui signifie que les managers de projet doivent s’engager dans une réflexion systémique pour générer une performance positive du projet.

Voici quelques perspectives significatives sur la pensée systémique qui améliorent la performance du projet.

Le changement au niveau du business de l’entreprise est l’objectif (pas seulement l’achèvement du projet).

l’objectif business est souvent bien plus large que l’objectif du projet

Les organisations intelligentes clôturent les projets lorsqu’elles ont atteint les résultats business souhaités, et non pas lorsque les livrables du projet sont terminés. Dans un monde projets, l’intégration de l’analyse d’affaires (business analysis), du management de projet et du changement organisationnel sont au cœur de la pensée systémique.

Par exemple, un nouveau processus opérationnel ou une nouvelle description de produit devrait mener à un plan de production de livrables. Ce plan décrira la valeur commerciale souhaitée. Au fur et à mesure que les livrables sont produits, les parties prenantes ont besoin de conseils de mise en place du changement organisationnel pour s’assurer que les produits et les changements opérationnels génèrent cette valeur.

Bâtissez sur le passé.

Les livrables du projet peuvent être plus efficaces lorsqu’ils tirent parti de ce qui est déjà mis en place via d’autres projets. Les approches agiles le font bien et rapidement. Parce que les livrables sont déployés en sprints courts, le processus agile s’appuie constamment sur le passé en améliorant les fonctionnalités qui ne sont pas aussi efficaces qu’elles pourraient l’être et en développant les fonctionnalités qui ajoutent déjà de la valeur commerciale. Néanmoins, vous n’avez pas besoin d’agilité pour construire sur le passé.

Les projets classés dans des portefeuilles bien organisés représentent souvent des étapes vers un ensemble stratégique de changements. En cours de route, de nouvelles exigences et de nouveaux besoins de l’entreprise créent des obstacles ou des opportunités qui doivent être managés.  Vous pouvez améliorer les performances du projet en comprenant les objectifs de chaque projet du portefeuille et la valeur qu’ils apportent à l’entreprise. Ensuite, vous pouvez déterminer comment intégrer des objectifs business nouvellement découverts dans une liste de projets.

Comprenez les « dominos ».

Le changement est une constante dans le monde des affaires. Les changements d’activité, les changements de personnel et les nouvelles exigences peuvent créer une cascade d’éléments à traiter.

Par exemple, un changement dans un projet de construction modifie la triple contrainte de contenu, de coût et de délais. Mais il peut également modifier les contrats des sous-traitants, les processus des fournisseurs, le financement et les exigences en matière d’inspection.

Comprendre les changements en cascade qui surviennent au cours d’un projet et les aborder de manière proactive est un moyen fondamental par lequel la pensée systémique stimule les performances du projet.

L’intégration est un processus HUMAIN.

L’intégration des produits est difficile car les produits ne s’assemblent pas toujours comme prévu. Cela peut entraîner des retards dans les projets et des budgets qui augmentent. Un exemple est la sonde vers Mars qui a été perdue en raison d’un simple échec d’intégration, lorsqu’un module utilisait des mesures impériales et un autre utilisait les mesures métriques. La meilleure approche systémique de l’intégration consiste à travailler sur les personnes, les compétences et l’intégration des équipes.

Vos intégrations de produits se dérouleront sans heurts lorsque vous vous assurerez que les compétences que vous déployez ont des relations interpersonnelles positives et font preuve de respect les unes envers les autres et la contribution que chacune peut apporter.

Ces relations augmentent l’efficacité de la communication et le sentiment d’un objectif commun. De meilleurs produits, avec moins d’éléments d’intégration manqués, sont le résultat lorsque les équipes travaillent plus efficacement ensemble.

CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.
Pour en savoir plus sur le management de projets, consultez mon cours Project Management Foundations.

“PMI,” “PMBOK,” “PM Network” and “Project Management Institute” are registered marks of Project Management Institute, Inc.

Ne vous moquez pas trop vite par Christian Hohmann

Comme toujours, Christian nous donne matière à réflexion : Les apparences évidentes peuvent s’avérer incomplètes et trompeuses.

Ceci vous arrive-t-il également dans vos projets ?

Vous rappelez-vous d’une situation dans laquelle le refus de changement de certaines de vos parties prenantes était pleinement justifié ?

La matrice contrôle/responsabilité

Dans de nombreuses situations, vous avez la liberté de choisir vos préférences en matière de contrôle et de prise de responsabilités.

The control/responsibility matrix par Seth Godin

https://seths.blog/2022/01/the-control-responsibility-matrix/

La matrice contrôle/responsabilité

Les gens font des choix quant à leurs préférences en matière de contrôle et de prise de responsabilité. Lorsque nous combinons ces choix, nous nous retrouvons avec une matrice assez simple.

En haut à droite se trouve une combinaison idéale. Quelqu’un avec le contrôle et l’autorité qui prend également la responsabilité quand les choses tournent mal. Cela crée une boucle de rétroaction utile, car ces personnes peuvent réellement faire quelque chose à propos des problèmes qu’elles ont causés.

En bas à droite se trouve une catastrophe en attente de se produire. C’est un mégalomane fragile, Robert Moses, un bâtisseur, qui a passé près d’un siècle à paver New York tout en négligeant le logement et autres questions de justice sociale, mais n’a jamais assumé la responsabilité des effets de son travail. Les personnes qui prennent le contrôle et évitent la responsabilité sont souvent facilement identifiables parce qu’elles passent beaucoup de temps à se plaindre.

Dans le coin supérieur gauche se trouve ceux qui s’en soucient vraiment. Ils apportent une énorme empathie à la situation et aident les gens à se sentir reconnus. Hélas, parce qu’ils n’ont pas de pouvoir (soit parce qu’on leur a refusé, soit parce qu’ils l’évitent), leur volonté de prendre leurs responsabilités est en quelque sorte creuse. C’est l’une des raisons pour lesquelles les travailleurs de première ligne qui doivent exercer un travail émotionnel et faire preuve d’empathie au travail s’épuisent si souvent.

Et enfin, dans la plupart des situations, la majorité des gens sont en bas à gauche. Le système nous pousse à être des rouages, à accepter ce qui est donné en échange d’être blanchis et de ne pas être tenus responsables de ce qui se passe ensuite.

Dans de nombreuses situations, nous avons la liberté de choisir. Nous pouvons choisir un quadrant ou nous pouvons choisir de ne pas participer. Et si nous sommes assez chanceux ou attentionnés, nous pouvons choisir pour qui voter, pour qui travailler et où nous allons.

Quand c’est flou c’est qu’il y a un loup !

Ce dicton est particulièrement applicable dans le monde des projets que vous en soyez le manager de projet, le sponsor, le leader, un membre de l’équipe ou même une partie prenante plus éloignée.

En matière d’alignement de l’équipe projet, l’ambiguïté est votre ennemi.

Faites l’assomption qu’une personne ou un service va prendre en charge certaines tâches dont votre projet dépend parce que c’est dans sa description de poste ou la fonction attendue de ce service et cela risque fortement de vous conduire à une catastrophe majeure.

En plus de clarifier les rôles, la question du « Qui fait quoi ? » crée également une opportunité de clarifier les échéances et de confirmer leur faisabilité.

En tant que manager de projet, vous allez, pendant que l’équipe discute des mesures à prendre pour atteindre les objectifs ciblés, vous assurer que chaque action est bien assignée à une personne ou à une équipe spécifique et qu’une date limite précise et acceptée de cette personne/équipe est confirmée.

Capturez par écrit ces engagements et distribuez ceux-ci à l’équipe sous forme de compte rendu de réunion de travail.

Préciser avec tous « qui fait quoi » peut vous sembler une étape évidente et même inutile car toute l’équipe projet, en particulier en approche Agile, connait les objectifs et les compétences de chacun.

Mais, ne le faites pas et vous risquez fort d’attendre des semaines qu’une personne termine une tâche dont elle n’a aucune idée qu’elle était censée la faire !

Levez toutes les ambiguïtés liées à « Qui fera Quoi » et vous avez déjà fait un énorme pas vers la réussite !

Comme le dit David Burkus « Ambiguity is the ennemy of clarity ».

La valeur du Management de Portefeuille de Projets IT par René Klunder van Gijen

Il est crucial pour les entreprises et l’IT de travailler en équipe pour atteindre l’objectif commun : Ajouter de la valeur à l’entreprise et à ses parties prenantes et clients.

The value of IT Portfolio Management

https://feetontheground.nl/the-value-of-it-portfolio-management/ par René Klunder van Gijen

Le but du management de portefeuille de projets est de déterminer quelles initiatives ajoutent le plus de valeur à l’entreprise et à ses clients. Il est important de tenir compte des délais dans lesquels les initiatives commenceront à ajouter de la valeur.

Il y a deux ans, avec l’équipe @DKR, j’ai fait une randonnée cycliste caritative de sept jours des Pays-Bas à l’Alpe d’Huez en France, appelée le Gran Fondo. L’une des clés du succès a été notre feuille de route. Cela nous a donné une direction, une structure et un focus. Nous avions un plan.

Ici, je constate un énorme parallèle avec le Management de Portefeuille de projets IT, IT Portfolio Management. Vous avez besoin d’un plan et d’une structure pour donner une direction au management de portefeuille afin de pouvoir déterminer quelles initiatives se qualifient le mieux pour ajouter de la valeur.

Exécution de la stratégie

Le management de portefeuille est un élément important du modèle d’exécution de la stratégie.

En cette ère numérique, de nombreuses entreprises sont inondées de demandes des clients pour de nouveaux produits et services. Il en résulte de nombreuses initiatives informatiques générées par le business.

Mais comment une organisation peut-elle rationaliser et sélectionner les initiatives qu’elle développera et lancera ?

C’est là qu’intervient l’Organisation de Management de Portefeuille ou PFMO. Son rôle est de prioriser les initiatives qui doivent mener à une proposition de feuille de route pour décision finale par le Comité Décisionnel du portefeuille, le board. Ce board est un organe de gouvernance mis en place et mandaté par la direction de l’organisation.

Priorisation des initiatives

Lorsque nous avons planifié le Gran Fondo, nous avons dû faire des choix. Sur la base de la condition physique de l’équipe, de combien de kilomètres et de dénivelé l’équipe pourrait-elle accomplir de manière réaliste en sept jours ? Les sept étapes ont dû être adaptées à cela en tenant compte également d’autres éléments, tels que les routes qui n’étaient pas ouvertes aux cyclistes et l’emplacement des hébergements.

Dans le management de portefeuille, les mêmes principes s’appliquent. Des choix doivent être faits et il est nécessaire d’établir des priorités.

Les critères typiques de priorisation des initiatives sont les suivants
  • Contribue-t-elle à la stratégie de l’organisation ?
  • Comment aide-t-elle à atteindre les objectifs que l’organisation s’est fixés et contribue-t-elle à l’atteinte des avantages escomptés ?
  • Les cadres juridiques auxquels l’organisation doit se conformer sont-ils en jeu ? Par exemple, les règles liées à la protection de la vie privée et à la sécurité.
  • Est-elle conforme à l’architecture technique de l’entreprise ?
  • Quand l’initiative pourra-t-elle commencer à ajouter de la valeur à l’entreprise et à ses clients ? Ceci en fonction de la durée, de l’échelonnement, de la taille, de la complexité et de l’impact sur les ressources.
  • Le produit/service envisagé est-il reproductible ? Peut-il être utilisé chez d’autres clients ?
  • Quelles sont les dépendances et l’impact sur les autres initiatives et le portefeuille actuel de produits et services ?

De toute évidence, le budget est un élément important à considérer. Mais d’après mon expérience, les initiatives sont généralement financées par le demandeur, l’entreprise; ni par l’organisation informatique ni par le PFMO. C’est pourquoi je ne considère pas que cela fasse partie des critères de priorisation. Dans certains cas, j’ai vu le service informatique se voir accorder un budget annuel fixe pour effectuer, par exemple, des travaux de développement. Ceci sur la base de la feuille de route élaborée par le PFMO. Mais ensuite, une nouvelle initiative a été priorisée qui ne figurait pas sur la feuille de route et qui nécessitait davantage de capacités de développement. Cela a conduit à un financement supplémentaire pour l’IT afin d’assurer une capacité de développement suffisante.

L’examen et la priorisation des initiatives IT nécessitent une analyse approfondie de la part de l’Organisation de Management de Portefeuille (PFMO). Le Product Owner a un rôle clé à jouer pour mener l’analyse approfondie et impliquer les architectes techniques d’entreprise soutenus par des spécialistes.

Critères de succès

L’un des plus grands défis que j’ai vus est l’adoption du management de portefeuille par l’entreprise et l’utilisation du PFMO. Le rôle du PFMO est de fournir une vision holistique de toutes les initiatives informatiques et d’assurer une priorisation correcte pour l’organisation. Mais ces priorités ne correspondent pas toujours aux attentes des différentes unités opérationnelles.

Ici, je vois un parallèle avec le Gran Fondo. Tous les coureurs de notre équipe n’avaient pas le même niveau de forme physique. Nous courrions le risque que les coureurs veuillent faire leur propre choix en termes d’itinéraire, de montées et d’étapes. C’est pourquoi nous avons créé la feuille de route, le roadbook, qui a canalisé l’équipe. Suivre le roadbook nous a donné la meilleure chance d’atteindre notre objectif et de passer la ligne d’arrivée ensemble en tant qu’équipe.

Pour donner une direction à votre organisation et éviter le risque que les unités commerciales ne sortent du cadre du PFMO, je recommande de construire une structure solide de management de portefeuille informatique qui soit formellement approuvée au niveau de la direction.

Cette structure devrait servir de ligne directrice à l’organisation sur comment et quand utiliser le PFMO. Elle devrait décrire la gouvernance de management du portefeuille, son mandat, les rôles et responsabilités et les routines de réunion.

Une vue de la gouvernance du portefeuille.

Un autre challenge est de savoir comment l’établissement des priorités, tel que réalisé par le PMFO, est traduit en une feuille de route. On s’attend souvent à ce que le comité de management du portefeuille, le board, établisse la feuille de route en fonction des priorités établies par le PMFO.

Avec l’afflux élevé de nouvelles initiatives numériques, le board n’est pas équipé pour élaborer une telle feuille de route. Souvent, les membres du comité font partie de l’équipe de direction. Ils n’ont tout simplement pas le temps ni la capacité et n’ont généralement pas les connaissances approfondies. Par conséquent, ma recommandation est de mettre en place un forum des propriétaires business et produits (portfolio forum of business and product owners) qui développe une feuille de route conceptuelle pour la prise de décision finale par le conseil d’administration. L’avantage est davantage de responsabilisation pour les équipes, plus de flexibilité et des propriétaires business et produits qui réfléchissent pour l’entreprise et pas seulement pour leur propre organisation.

Management des parties prenantes

Pour les unités commerciales, le délai de mise sur le marché et la rapidité de livraison de nouveaux produits/services aux clients sont d’une importance majeure.

Le risque est que les unités commerciales sortent du management de portefeuille si les exigences ne peuvent pas être remplies comme elles le souhaitent. Elles passeront probablement à côté de sujets importants tels que le respect des normes de l’entreprise (comme celles de confidentialité, techniques, standards de données) et génèreront de la duplication d’initiatives, ce qui signifie des investissements supplémentaires. Un bon exemple que j’ai rencontré était le développement d’une application de reconnaissance faciale qui n’était pas conforme aux normes de l’entreprise.

Comme indiqué précédemment, il est essentiel de rendre obligatoire pour l’entreprise de mener toutes les nouvelles initiatives par l’intermédiaire du PFMO.

Cependant, le PFMO doit se rendre compte que le management de portefeuille n’est pas l’activité principale des principaux contributeurs de l’entreprise. Surtout au début, il faut de gros efforts pour les embarquer dans le voyage du management de portefeuille et leur faire comprendre la valeur du management de portefeuille, le rôle qu’ils jouent, le mandat qu’ils ont et l’environnement dans lequel ils opèrent.

Par conséquent, passez du temps avec les parties prenantes de l’entreprise, non seulement par le biais de la gouvernance formelle, mais aussi par le biais de réunions individuelles. La communication est la clé.

Nous avons vécu la même chose dans notre Gran Fondo. Certains cyclistes ont mal interprété le roadbook, et nous nous sommes trompés de sortie. Cependant, en communiquant et en nous orientant collectivement dans la bonne direction, nous sommes revenus en piste et nous avons franchi la ligne d’arrivée ensemble.

Les points à retenir

  • Produisez un « roadbook », feuille de route, pour structurer l’orientation du management de portefeuille dans votre organisation.
  • Obtenez l’adhésion de la direction exécutive, car elle est essentielle pour vous assurer que toutes les nouvelles initiatives IT au sein de l’organisation passeront par l’organisation de management de portefeuille.
  • Établissez une structure de portefeuille pour fournir des directions sur la façon dont l’entreprise et le service informatique collaborent pour faire les bons choix pour l’organisation en termes d’initiatives à prioriser et à déployer.
  • Laissez l’organe de management de portefeuille déterminer quelles initiatives/projets contribuent le plus aux thèmes stratégiques de l’organisation et lesquels peuvent apporter le plus de valeur à l’organisation dans les plus brefs délais.
  • Embarquez les parties prenantes seniors sur le chemin du management de portefeuille.
  • Rappelez-vous, comme le Gran Fondo, il est crucial pour les entreprises et l’IT de travailler en équipe pour atteindre l’objectif commun : Ajouter de la valeur à l’entreprise et à ses parties prenantes et clients.

Qui est René Klunder van Gijen (avec lequel j’ai eu le privilège de travailler chez Orange) ?

René Klunder van Gijen

I’m an experienced Business Unit and Transformation Leader. I’m passionated about building high performance teams, help customers in their transformation and help them to achieve their business objectives. 

I have a solid background in ICT and Telecoms. I’m used to operate at the cutting edge of business and ICT /Telecom and I have worked in both domestic and international B2B environments.

Building bridges between teams and departments is one of my key qualities.

Quelles questions se poser face à une potentielle innovation ?

Voici quelques questions que nous suggère Seth Godin face à une potentielle innovation.

Innovation and domain knowledge par Seth Godin

https://seths.blog/2022/01/innovation-and-domain-knowledge/

Cela a-t-il déjà été fait auparavant ?

Pourquoi pas ?

Cela a-t-il fonctionné ?

Pourquoi pas ?

Si c’est nouveau et utile, quel problème cela résout-il ?

Pourquoi le public visé a-t-il rejeté des innovations similaires dans le passé ?

Un jour, ce marché changera. Qu’est-ce qui provoquera ce changement ?

Gérer des projets sans expertise métier ! par Mehdi ELGUARNI

Gérer des projets consiste bien à gérer une équipe projet qui s’occupera de livrer de la valeur sous forme de livrables répondant aux exigences de certaines parties prenantes.

Aussi, gérer un projet nécessiterait, selon le Project Management Institute® (PMI), 3 talents essentiels.

  1. Méthodes de travail (Ways of working) : Concerne les approches et les techniques de management de projet et la manière de livrer plutôt que le métier en soi.
  2. Compétences de pouvoir (Power skills) : Renvoie à tout ce qui se rapporte au leadership collaboratif et à la communication avec les équipes pour les orienter vers un objectif précis.
  3. Sens des affaires (Business acumen) : Consiste à garder un alignement avec les objectifs business de l’organisation sponsor du projet.

Alors quid des compétences techniques relatives au métier cœur du projet ?

ingénieur techniqueN’est-il pas nécessaire de maîtriser les tenants et les aboutissants du domaine dans lequel on opère ?

Quel serait l’impact d’un tel gap sur la légitimité du chef de projet ou même sur les performances du projet ?

Et comment compenser le manque d’expertise par une autre compétence ?

Un chef de projet est un leader qui aura besoin d’user de ses pouvoirs pour mener l’équipe vers la réussite du projet.

Toutefois, son pouvoir provenant de son statut formel n’est pas toujours suffisant pour réussir à influencer les membres de son équipe. Il aurait besoin de l’expertise métier pour compléter encore sa légitimité surtout dans un monde où l’autorité hiérarchique fait, de plus en plus, place à l’influence et la collaboration. De plus, s’appuyer trop sur son pouvoir hiérarchique quand les choses vont mal, pourrait avoir l’effet inverse et causer la perte de la cohésion de l’équipe. Alors, que faire sachant qu’en tant que Chef de projet, on est souvent le visage du projet pour le management et les clients ?

La solution optimale pourrait être le fait de privilégier « temporairement » la complémentarité plutôt que l’autorité positionnelle.

« Temporairement », car un jour ou l’autre on serait rattrapé par la nécessité de comprendre le métier, de parler le jargon et de vivre avec l’équipe les contraintes techniques plutôt que de garder tout ceci consigné dans des registres d’hypothèses et de contraintes sans le maîtriser en profondeur. Et la complémentarité revoie au fait d’apporter son savoir-faire en management de projet, sujet sur lequel on va être l’expert, pour contribuer avec l’équipe à arracher une belle réussite du projet. Ainsi, on aurait affirmé sa position d’expert en management de projet tout en vivant pleinement le projet avec son équipe.

Un chef de projet est aussi un intégrateur du projet qui devrait disposer d’une vision à 360° de ce qui se passe dans le projet, l’organisation et même dans le secteur d’activité.

Ceci aide à bien scanner l’environnement des risques mais exige un minimum de compréhension du métier du projet. Par conséquent, ne pas essayer de combler le vide expose le projet à des risques majeurs, des risques qui resteront non identifiés ou sous-estimés. Alors, comment faire face à cela dans un monde, de plus en plus, incertain, volatile et complexe ? La réponse magique est « l’avis des experts ».

Dans chaque organisation et chaque projet, on retrouve des collaborateurs qui ont bien roulé leur bosse dans un domaine spécifique et qui disposent à la fois de l’expertise technique, d’une grande expérience sur des projets similaires et bien d’autres connaissances tacites plutôt qu’explicites. Tout ce trésor bien gardé est une ressource inestimable pour le chef de projet qui en aurait besoin pour étoffer son processus de gestion des risques afin d’immuniser son projet contre des surprises malencontreuses. Encore une fois, il faudrait bien faire l’effort de monter en compétence sur le métier et ne pas toujours reposer son évaluation des risques sur l’avis des experts qui contient souvent une belle part de subjectivité.

Le management de projet étant un métier à part et relativement indépendant du domaine où l’on exerce, plusieurs chefs de projets, au fil de leurs carrières, changent d’entreprise, de domaine ou carrément de secteur d’activité.

Ceci les met face à une nouvelle réalité où les priorités ne sont pas les mêmes et où la valeur n’est pas perçue de la même manière. Là encore, s’il y avait quelque chose d’urgent et d’important à faire, ce serait d’échanger le plus possible avec les experts du métier et ses pairs et de consulter les archives et les documents des projets antérieurs. Cela permettrait, de réussir une navigation à deux vitesses, en gérant le projet au quotidien tout en rattrapant l’équipe en termes de connaissances métier.

En fin, ce qui fait la vraie richesse d’un chef de projet, c’est le fait d’avoir accumulé des expériences sur différents domaines, exercé différents métiers et surtout de disposer de suffisamment de courage pour aller à la recherche de nouveaux défis.

Il faudrait juste disposer de l’humilité nécessaire pour ouvrir son esprit à toute information utile à la réussite de ses projets.

“PMI,” the PMI logo, “PMP,” “PMBOK,” “PM Network,” “Project Management Institute” and “Pulse of the Profession” are registered marks of Project Management Institute, Inc.


Mehdi Elguarni

ELGUARNI Mehdi est ingénieur diplômé des Arts & Métiers et de l’École des Ponts ParisTech, certifié PMP®, Prince2, ISO31000, SMAC et SPOAC et actuellement Chef de Projet dans le secteur des Énergies.

Mehdi a géré des projets pendant 9 ans dans des projets de construction, de maintenance, d’études et de digitalisation.

Mehdi est aussi formateur en management de projet, bénévole du PMI France et rédacteur d’articles pour le PMI Lévis-Québec.

Le hack du sauveteur

Le maître-nageur n’a pas d’excuses ni de bonnes raisons de ne pas intervenir si quelqu’un se noie.

https://seths.blog/2021/11/the-lifeguard-hack/ par Seth Godin

Qui suis-je pour m’approcher de quelqu’un lors d’une soirée et me présenter ?

Qui êtes-vous pour démarrer un nouveau projet ?

Qui sont-ils pour donner une conférence sur la scène principale ?

Ne levez pas la main, quelqu’un d’autre pourrait avoir une meilleure question. Ne livrez pas ce travail, il n’est pas prêt…

Il y a des excuses, des comparaisons et des raisons infinies de se retenir.

Sauf si…

Sauf si vous êtes maître-nageur et que quelqu’un se noie. Dans cette situation, même si vous n’êtes pas le meilleur sauveteur du monde, et même si l’eau n’est pas à la parfaite température, et même si vous ne vous souvenez pas très bien comment faire la dernière version du porté croisé sur la poitrine… Vous sautez à l’eau.

Parce que ce n’est pas pour vous. C’est pour eux.

La générosité ouvre des portes à l’intérieur de vous.


Le manager de projet se doit également d’intervenir si des membres de l’équipe rencontrent des difficultés qui mettent le projet en péril.

Sans pour autant se prendre pour superman ou superwoman capables de résoudre seuls tous les problèmes et risques qui se présentent sur le projet.

Travailler en solo ou collaborer ? Comment choisir en fonction de ce qui vous bénéficie le mieux.

Quels sont les avantages et inconvénients de ces deux modes de travail, en solo et en équipe, et comment trouver le bon équilibre ?

Work Solo or Collaborate? How to Choose Based on What Benefits You

Pragmatic Manager Newsletter par Johanna Rothman

Préférez-vous le travail collaboratif ou en solo ?

Certains d’entre vous préfèrent travailler seuls parce que vous savez être efficaces, même si votre travail n’est pas indépendant du travail des autres. Ou, si vous travaillez dans le cadre d’un groupe de travail, tel que les ressources humaines ou les finances, vous ne partagez qu’un objectif départemental, pas un objectif produit. Les groupes de travail peuvent ne pas avoir besoin de collaborer car leur travail peut être indépendant des livrables de quelqu’un d’autre.

Je vois trop de facteurs qui dissuadent de collaborer, même lorsque des personnes font partie d’équipes produits ou fonctionnalités, lorsque ces équipes partagent un objectif commun.

Mais, parfois, cela dépend non seulement du type de travail, mais aussi du contexte culturel.

Avantages du travail en solo

La plupart des gens me disent qu’ils aiment le travail en solo parce qu’ils peuvent se concentrer. Cette approche « d’entrée dans la zone » vous permet de :

  • Avoir l’impression de travailler plus vite,
  • Aimer résoudre le problème, et
  • Obtenir la satisfaction de finir quelque chose.

Vous sentez que vous avez davantage d’autonomie, de maîtrise et de sens lorsque vous travaillez seul.

Mais que se passe-t-il lorsque votre travail doit s’insérer ou s’intégrer au travail d’autres personnes ? L’un d’entre nous, même concentré, pourrait retarder tout le travail. (Vous pouvez mesurer le temps de cycle pour mesurer et visualiser ces délais.)

Bien que les gens puissent travailler seuls, le travail n’est pas indépendant.

C’est pourquoi je recommande aux responsables et aux équipes produit/fonctionnalité de collaborer dans leur travail.

Avantages du travail collaboratif

Lorsque vous collaborez même avec une seule personne, vous pouvez :

  • Intégrer les commentaires au fur et à mesure que vous apprenez et améliorez le produit.
  • Établir la confiance et le respect avec les autres pendant que vous travaillez. D’après mon expérience, les managers sous-estiment la valeur de la confiance et du respect parce qu’il s’agit d’avantages intangibles.
  • Mener une évaluation continue de pourquoi et comment vous faites ce travail.

Cependant, la collaboration n’est ni pour tout le monde ni pour chaque équipe ou groupe de travail. Souvent, c’est à cause de la culture de votre organisation.

Considérations culturelles

À quel point êtes-vous occupé ? Vous démenez-vous pour atteindre votre objectif quotidien ou hebdomadaire parce que vous avez tellement de travail individuel à compléter ? C’est un signe que vos managers pensent à l’efficacité des ressources, pas à l’efficacité des flux. Vous pouvez choisir de collaborer avec d’autres, mais vous sentez-vous suffisamment en sécurité pour le faire, surtout si vous pensez que soutenir quelqu’un d’autre pourrait affecter négativement votre salaire ou votre prime.

Mais vous pourriez aussi vous sentir en danger pour d’autres raisons. Parfois, les managers croient que des personnes 10x  (des surhommes) existent. Ensuite, les managers permettent aux supposées « superstars » de travailler comme des « empêcheurs ». Les empêcheurs détruisent le potentiel travail d’équipe et renforcent une culture désagréable.

Considérez vos options viables

Je vois ces options, surtout si vous vous sentez débordé de travail :

  • Gardez la tête baissée et continuez à travailler seul. Oui, c’est une option viable et raisonnable. Vous terminerez votre travail, même si vous n’aiderez pas l’organisation à livrer le produit plus rapidement. Et cela ne vous aidera pas à apprendre plus vite. Mais vous protégerez votre salaire et votre prime.
  • Soulevez l’idée de collaboration avec votre manager. Demandez à votre manager comment la collaboration pourrait les affecter, lui et sa structure de rémunération.
  • Envisagez des rencontres individuelles pour socialiser le concept de collaboration. Vous pouvez commencer par collaborer à deux, en tête-à-tête.

Vous pouvez imaginer d’autres options…

Le travail solo diffère du travail indépendant

De nombreux managers croient que les gens peuvent travailler en solo parce que le travail de chaque personne est indépendant de l’autre. Cela peut être vrai pour un groupe de travail, tel que les ventes, les finances ou les ressources humaines. Mais ce n’est pas vrai pour les équipes de développement de produits.

Bien que vous puissiez travailler de manière indépendante, beaucoup d’entre vous apprennent mieux lorsque vous travaillez – au moins un peu – avec les autres. Considérez vos options pour le travail solo ou collaboratif et ce que vous ferez pour créer la culture souhaitée.

Apprenez avec Johanna

Je suis presque prête à annoncer le writing workshop du premier trimestre 2023. En attendant, n’hésitez pas à vous ajouter à la liste de diffusion si vous pensez que vous pourriez vouloir suivre cet atelier à l’avenir.

J’envisage également d’offrir  des ateliers de management publics. Jusqu’à présent, je ne les proposais que sous forme d’ateliers privés internes. Si vous êtes intéressé par de tels ateliers, jetez un coup d’œil à cette page et ajoutez-vous à la liste de diffusion.

Nouveau avec le Pragmatic Manager ? Lisez les numéros précédents.

Comment allouez-vous et restituez-vous les réserves pour imprévus ?

Comment cette réserve de budget pour les imprévus est-elle répartie au fil du temps et remise à l’organisme de financement si elle n’est pas utilisée ?

How are you allocating and returning contingency reserves? par Kiron Bondale

https://kbondale.wordpress.com/2022/06/05/how-are-you-allocating-and-returning-contingency-reserves/

La plupart des managers de projet incluront des réserves pour imprévus (aussi appelées fonds de contingence) dans leur budget pour compenser les répercussions financières négatives de risques qui se matérialiseraient. La détermination du montant à mettre de côté pour un jour de mauvais temps sur le projet pourrait être effectuée à partir d’une méthode descendante, telle que l’utilisation d’un pourcentage fixe dérivé de projets antérieurs (p. ex., les projets de faible complexité auront une réserve pour imprévus de 10 %, tandis que les projets plus complexes auront 25 %) ou une approche ascendante fondée sur l’évaluation et l’agrégation de la valeur monétaire attendue des impacts financiers des principaux risques.

Mais comment cette réserve est-elle répartie au fil du temps et remise à l’organisme de financement si elle n’est pas utilisée ?

Il y a quatre approches courantes que j’ai rencontrées :

  1. Allocation sous la forme d’un montant forfaitaire unique (c.-à-d. non séquencé dans le temps) et détenu pendant toute la durée du projet. En d’autres termes, les réserves pour imprévus ne sont pas libérées tant que le projet n’est pas terminé.
  2. Allocation à des jalons ou à des phases de projet spécifiques et conservé pendant toute la durée du projet.
  3. Allocation sous la forme d’une somme forfaitaire unique, mais retournée à un rythme progressif en fonction de la matérialisation réelle des risques pendant la durée de vie du projet.
  4. Allocation à des jalons ou à des phases de projet spécifiques, les montants inutilisés étant retournés au fur et à mesure que chaque jalon est atteint ou que chaque phase est terminée.

#1 et #4 sont les deux dont j’ai été le plus souvent témoin, mais comme d’habitude, je voulais comparer mon expérience avec celle de la communauté de management de projet au sens large.

J’ai mené un sondage d’une semaine dans le groupe de discussion LinkedIn Project, Program and Portfolio Management de PMI, ainsi que dans la communauté ProjectManagement.com.

J’ai reçu 56 réponses avec la répartition suivante :

  1. 45% ont voté pour le montant forfaitaire unique sans retour jusqu’à la fin du projet
  2. 7% ont voté pour les sommes séquencées dans le temps sans retour jusqu’à la fin du projet
  3. 13% ont voté pour le montant forfaitaire unique avec rendement progressif
  4. 35 % ont voté pour les sommes séquencées dans le temps avec des rendements basés sur l’étape ou l’achèvement de la phase

Cela correspond à mon expérience, mais j’ai été agréablement surpris de voir que la quatrième option a reçu plus d’un tiers des votes, car elle indique un niveau de maturité plus élevé que ce à quoi je m’attendais. Bien sûr, cela pourrait aussi être le résultat d’un biais dans l’échantillon de sondage en faveur de praticiens plus compétents.

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

J’ai reçu deux commentaires particulièrement perspicaces dans ce sondage.

Le premier est que cela dépend des conséquences pour les dépassements et les sous-consommations. Plus la pénalité est importante, plus il est probable que les réserves pour imprévus seront conservées et entièrement utilisées pendant la durée de vie d’un projet.

L’autre commentaire indiquait que, comme les réserves sont liées aux risques, certains risques peuvent ne pas avoir un seul délai de réalisation prévu et qu’il pourrait donc devenir difficile d’affecter uniquement les montants des réserves pour éventualités au niveau des jalons ou des phases et que la majeure partie pourrait être liée à l’achèvement final du projet.

Bien qu’il soit beaucoup plus facile de calculer un montant forfaitaire unique pour les réserves pour imprévus, cela ne permet pas aux autorités financières de prévoir quand ces réserves pourraient être utilisées et à quel rythme. Et bien que les managers de projet peu enclins à prendre des risques puissent être réticents à rendre des réserves jusqu’à ce que le projet soit terminé, ils doivent comprendre que conserver ces fonds plus longtemps que nécessaire représentera un coût d’opportunité important pour l’organisation.

L’une des règles de Jerry Madden parmi les 100 règles de la NASA pour les chefs de projet (voir ci-dessous) se lit comme suit :

Tous les problèmes peuvent être résolus à temps, alors assurez-vous d’avoir suffisamment de contingence de calendrier. Si vous ne le faites pas, le prochain chef de projet qui prendra votre place le fera.

Alors que dans certains cas, vous aurez un projet qui ne peut absolument pas se terminer avec un jour de retard (pensez à Bruce Willis et Ben Affleck essayant d’empêcher cet astéroïde tueur de planètes de frapper la Terre dans le film Armageddon), les retards de calendrier signifieront rarement la fin du monde. Cependant, dépassez significativement le budget et vous souhaiterez que l’astéroïde soit sur le point de frapper la planète pour vous sauver de la veste que vont vous tailler vos autorités de financement !


Les 100 règles pour les managers de projets de la NASA (Billets précédemment publiés sur ce blog)

Leçons en management de projet de la NASA
Leçons en management de projet de la NASA

 

Lorsque vous devez justifier votre rôle de manager de projet…

Le management de projet est trop souvent considéré comme des frais généraux et ceux-ci deviennent une cible classique lorsque les réductions de coûts sont d’actualité.

When You Need to Justify Your Project Manager Role par Bonnie Biafore

http://www.bonniebiafore.com/when-you-need-to-justify-your-project-manager-role/

jeter l'argentLe management de projet est souvent considéré comme des frais généraux et ceux-ci deviennent une cible classique lorsque les réductions de coûts sont d’actualité. En conséquence, vous pourriez vous retrouver dans la position inconfortable de devoir justifier votre rôle de manager de projet.

Voici plusieurs approches que vous pouvez utiliser pour éduquer les dirigeants sur la valeur du management de projet et des managers de projet compétents.

Dissipez les craintes des managers.

Les managers ont généralement deux grandes préoccupations concernant le management de projet : Son coût et le fait que cela prendra plus de temps.

Commencez par souligner que la plupart des organisations affectent des chefs d’équipe au sein d’un service pour coordonner les tâches, attribuer les rôles et examiner les résultats. Ensuite, expliquez que le management de projet est essentiellement la même situation, sauf qu’elle fonctionne en transverse avec de nombreux départements et avec une large variété de parties prenantes.

Corrigez l’impression que les managers hiérarchiques peuvent manager des projets.

Les organisations se tournent parfois vers les managers hiérarchiques pour livrer des projets. Cela fonctionne rarement. Premièrement, les supérieurs hiérarchiques sont déjà trop occupés. Ils sont facilement distraits des tâches de management de projet par les exigences de leadership opérationnel qui sont incessantes et souvent urgentes.

En outre, les responsables hiérarchiques pourraient ne pas être perçus comme objectifs : Ils pourraient privilégier leur domaine technique et leurs objectifs de managers dans leurs décisions de projet. Enfin, les responsables hiérarchiques sont rarement formés aux techniques de management de projet, ce qui est au centre du point suivant.

Insistez sur l’importance de la formation et de l’expérience.

Rappelez aux dirigeants que l’organisation sélectionne les candidats en fonction de leur formation et de leur expérience, en appelant leurs références pour vérifier les affirmations des candidats.

Compte tenu des dépenses et de la valeur commerciale que les projets apportent, pourquoi ne pas évaluer les managers de projet de la même manière ?

Mettre l’accent sur la formation en management de projet et vérifier leur expérience et résultats lors de la réalisation de projets passés. Cela augmente les chances de réussite des projets.

Insistez sur le coût de l’échec du projet.

Selon Projectsmart, le coût moyen d’un projet informatique échoué est de $12 Millions (https://www.projectsmart.co.uk/the-real-costs-of-failed-projects.php). Et ce chiffre n’inclut pas le coût d’opportunité des bénéfices qui n’ont pas été réalisés.

Investissez pour la réussite des projets.

Bien que cette statistique ne représente pas toutes les industries, elle démontre le coût substantiel de l’échec du projet en monnaie sonnante et trébuchante et des bénéfices perdus. Rappelez aux dirigeants qu’il est bon d’investir dans des activités qui augmentent les chances de succès. L’adoption et l’amélioration du management de projet aident à protéger l’argent et le temps investis dans les projets et à s’assurer que ces projets produisent les résultats escomptés.

Si vous avez dû justifier le management de projet ou votre rôle de manager de projet, quelles techniques avez-vous utilisées ?
Qu’est-ce qui a fonctionné et qu’est-ce qui n’a pas marché ?

Pour en savoir plus sur la valeur du management de projet, consultez le parcours d’apprentissage LinkedIn Learning « Become a Project Manager ».

Visitez le site de notre partenaire Virage Group

Comment devenir la personne vers laquelle on se tourne naturellement ?

« How to Become a Go-To Person » par Dan Rockwell et Stan Endicott

https://leadershipfreak.blog/2022/08/27/saturday-sage-how-to-become-a-go-to-person/

  • Lorsque vos amis sont confrontés à des décisions cruciales dans la vie, vous voulez être leur interlocuteur.
  • Lorsque les genoux fléchissent et que les gens sont stressés, vous voulez leur donner de la force.
  • Lorsque les dirigeants autour de vous ont du mal, vous voulez qu’ils viennent vous chercher.

Comment devenir une personne de référence ?

#1. Une personne de référence développe sa sagacité

Apprenez et intégrez diverses expériences. Un sage n’évite pas douleur et déception. Les imbéciles répètent et souffrent. Un sage apprend et s’adapte.

Les expériences douloureuses vous permettent de vous connecter et d’influencer de manière authentique.

observez, regardezÉtudiez les gens. Une personne de référence s’épanouit en comprenant les gens. Certains sont calmes. D’autres sont bavards. Acceptez les gens.

Quand vous rejetez les gens, ils vous résistent.

Maintenez le vrai cap. Une personne de référence a un point de vue. Votre objectif se compose de valeurs, d’expériences et de désir de contribuer.

#2. Une personne de référence sait quand elle est pertinente.

Soyez proche lors de situations douloureuses.

Passez après une perte tragique ou une défaillance catastrophique. Un sage se rapproche quand les autres s’éloignent.

Évoquez doucement les expériences que les autres évitent. « Je suis vraiment désolé d’apprendre que vous avez été congédié », par exemple.

Soyez curieux lorsque les gens marchent sur un terrain non testé. Prenez un café avec une personne qui a mérité une grande promotion. Envoyez une note lorsque quelqu’un fait face à de nouvelles opportunités ou à de nouveaux défis.

Voyez ce qui n’est pas évident et entendez ce qui n’est pas dit.

Une personne de référence offre une valeur unique en voyant des choses qui ne sont pas évidentes et en entendant des choses qui ne sont pas dites.

#3. Une personne de référence pratique le Sherlocking.

Un sage voit comme Sherlock Holmes.

Sherlock a utilisé son talent à voir les choses que les autres ont manquées et entendre des choses que les autres ont ignorées pour tirer des conclusions inattendues.

Les gens ont vu la lumière lorsque Holmes a assemblé le puzzle.

Voyez ce que les autres manquent sans être arrogant. La grâce et la gentillesse élèvent le Sherlocking au-dessus de l’intrusion.

Dans « The Adventure of the Engineer’s Thumb », écrit par Sir Arthur Conan Doyle, Sherlock fait preuve de compassion et de gentillesse.

« Il est facile de voir que votre expérience n’a pas été banale, M. Hatherley », a-t-il déclaré. « Priez, allongez-vous et faites absolument comme chez vous. Dites-nous ce que vous pouvez, mais arrêtez quand vous êtes fatigué et gardez vos forces avec un peu de stimulant. »

5 compétences de Sherlock
  1. Mieux comprendre grâce à l’observation silencieuse. Voyez ce que les autres ne voient pas.
  2. Appréhender la situation dans son ensemble en écoutant attentivement. Écoutez ce qui n’est pas dit.
  3. Élargissez la perspective en vous élevant au-dessus des situations. Un sage voit où était le train, où se trouve le train et où va le train.
  4. Construisez de nouveaux points de vue en combinant de nouvelles observations.
  5. Ayez une vision claire en excluant les idées non pertinentes, les émotions distrayantes et les perspectives effrayantes.

Où que vous alliez, examinez soigneusement la situation avant d’enlever la laisse de votre chien.

Donna-Lynn Musgrave

Vous voyez, mais vous n’observez pas.

Sir Arthur Conan Doyle

Passez un contrat avec vous-même. Ayez le courage de dire : « Je veux être la personne vers laquelle on se tourne naturellement. »

Signature _____________________________ Date____________


Voici un exercice qui vous poussera à devenir un sage incontournable

  1. Énumérez 5 qualités admirables de votre sage de prédilection.
  2. Comment a-t-il ou elle développé ces caractéristiques ?
  3. Comment pourriez-vous développer les aptitudes qui font de vous un sage incontournable ?
CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Faire une différence (versus faire valoir un point)

Faire valoir un point n’est pas la même chose que faire une différence.

Making a difference (making a point) par Seth Godin

https://seths.blog/2021/08/making-a-difference-making-a-point/

Il existe d’innombrables façons de faire valoir un point. Vous pouvez clairement démontrer que vous êtes en colère, intelligent, concerné, plus fort, plus rapide ou mieux préparé que la personne avec laquelle vous échangez.

Mais faire valoir un point n’est pas la même chose que faire une différence.

Pour faire une différence, nous avons besoin d’empathie pratique pour réaliser que l’autre personne ne sait pas ce que vous savez, ne croit pas ce que vous croyez et pourrait ne pas vouloir ce que vous voulez. Nous devons partir de là où nous sommes et comprendre en un instant où elle est.

Si vous vous préoccupez vraiment du sujet, vous ferez le travail difficile pour apporter une réelle différence !

Lorsque nous faisons valoir un point, nous rejetons tout cela. Lorsque nous faisons valoir un point, nous établissons notre pouvoir d’une manière ou d’une autre, mais nous ne changeons probablement pas grand-chose.

Le changement se produit lorsque l’histoire que l’autre personne se raconte commence à changer. Si tout ce que vous faites est de faire valoir un point, vous leur avez exposé une histoire sur vous-même. Lorsque vous apportez un changement, vous les aidez à embrasser une nouvelle histoire sur eux-mêmes.

Et même si c’est plus amusant de faire valoir un point (et que vous vous sentez en sécurité, d’une certaine manière), si vous vous préoccupez vraiment du sujet, vous ferez le travail difficile pour faire plutôt une réelle différence.

CSP DOCENDI est partenaire de DantotsuPM, visitez leur site pour découvrir leurs offres de formation.

Bénéfices moins connus du management des risques

Les disciplines de management de projet telles que le management des risques apportent le contrôle à un projet. En plus des avantages bien connus de ces disciplines, elles offrent d’autres bénéfices qui ne sont pas souvent discutés ni reconnus.

Less Well-known Benefits of Risk Management par Bonnie Biafore

http://www.bonniebiafore.com/less-well-known-benefits-of-risk-management/

Voici quelques avantages supplémentaires qu’offre le management des risques.

Vous encouragez l’optimisme.

Penser à ce qui pourrait mal tourner augmenterait l’optimisme ? Cela semble contre-intuitif, et pourtant c’est le cas ! Les plans de réponse aux risques peuvent encourager l’équipe. Quoi qu’il arrive, vous avez déjà identifié une action à entreprendre !

L’optimisme et contagieux, le sourire aussi !

En outre, la planification des risques positifs (également appelés opportunités) peut augmenter les chances que de bonnes choses se produisent et vous assurer d’en tirer le meilleur parti lorsqu’elles se produisent. C’est certainement une raison d’être optimiste !

Vous réduisez la pression.

Les managers de projet font face à suffisamment de pression sans avoir à développer des solutions aux problèmes dans l’instant. Avec le management des risques, vous avez des réponses pré-planifiées aux événements qui se produisent : vous êtes prêt à exécuter le plan afin que l’équipe puisse agir rapidement.

Même si un problème survient qui ne figure pas dans votre plan de management des risques, une équipe habituée à gérer les risques peut intervenir pour discuter des solutions de rechange et élaborer des réponses. Vous n’avez pas à y faire face tout seul !

Vous identifiez les possibilités.

Des réunions productives d’identification des risques et de planification de la réponse peuvent faire émerger bien plus que des réponses pessimistes. Vous pouvez lancer des actions de réduction des risques de manière proactive, ce qui non seulement répond aux risques, mais peut également augmenter la valeur du projet.

Vous savez identifier en équipe les possibilités et les options.

Par exemple, supposons que vous engagez de manière proactive une ressource qualifiée pour réduire les risques. Les compétences et l’expérience de cette personne pourraient révéler des solutions possibles qui augmentent la valeur que le projet apporte à l’entreprise.

Vous concentrez davantage le focus sur les résultats.

Focaliser régulièrement l’équipe de projet sur les risques lors des réunions d’état d’avancement garde l’objectif du projet à l’esprit. Alors que les membres de l’équipe de projet se concentrent naturellement sur leurs tâches spécifiques, le management des risques met l’accent sur ce qui pourrait compromettre les résultats du projet et sur la façon dont les membres de l’équipe peuvent travailler les uns avec les autres et avec la direction pour produire les résultats du projet comme prévu.

Avez-vous rencontré d’autres avantages de la gestion des risques qui ne sont généralement pas discutés ?
Partenaire de DantotsuPM, visitez le site pour toutes les formations certifiantes proposées

Le bon outil pour le travail

Chez les managers de projets comme dans de très nombreuses autres professions, les différences entre adopter et bien utiliser le bon ou le mauvais outil sont du temps, de l’argent et de la sécurité !

The right tool for the job by Seth Godin

C’est presque un cliché chez les menuisiers et autres artisans qui créent avec leurs mains. La différence entre le bon et le mauvais outil est du temps, de l’argent et de la sécurité. La satisfaction d’avoir un levier approprié à votre effort est extraordinaire.

Il est autant question de qualité d’outillage que de savoir bien se servir des outils que l’on a !

Regarder les gens se débattre avec leur téléphone ou leur ordinateur portable est triste et frustrant. Les gens continuent d’utiliser de mauvais outils. Peut-être que ce sont ceux qu’ils ont appris à utiliser il y a longtemps. Peut-être qu’ils sont arrivés gratuitement avec l’appareil. Plus probablement, ils sont le résultat d’une société de développement de logiciels qui ne prend pas suffisamment en compte les besoins de l’utilisateur.

Il existe probablement un meilleur outil numérique pour ce que vous essayerez de faire la prochaine fois en ligne. Cela vaut peut-être la peine de prendre quelques instants pour vous questionner, découvrir et apprendre.

Investissez une fois, profitez-en pendant très longtemps.

Téléchargez aussi ce guide sur le site de notre partenaire Virage Group

Qu’est-ce qui challenge le plus vos équipes avec Scrum ?

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

What challenges teams most with Scrum? de Kiron Bondale

https://kbondale.wordpress.com/2022/03/20/what-challenges-teams-most-with-scrum/

L’un des clichés à propos de Scrum est qu’il est « facile à comprendre mais difficile à maîtriser ».

Guide téléchargeable gratuitement

La première partie de ce cliché est évidente car le Guide Scrum ne comporte que 11 pages (si vous ne comptez pas la page de titre, l’objectif et la table des matières). Il y a 3 rôles, 3 livrables et 4 événements/cérémonies (cinq si vous incluez les sprints en tant qu’événement, mais je préfère ne pas le faire car l’idée générale d’événements dans des événements me donne la nausée).

La deuxième partie de ce cliché devient apparente une fois que vous essayez d’implémenter Scrum dans un système existant. Ce n’est que dans de très rares cas qu’il est possible d’introduire Scrum sans affecter radicalement la façon de travailler de l’équipe. Ceci, en soi, n’est pas une mauvaise chose car l’amélioration des résultats de livraison implique un certain nombre de changements.

Cependant, la nature immuable de Scrum est l’endroit où les défis se matérialisent. En surface, introduire un nouvel ensemble d’événements ou de livrables ne semble pas trop drastique, mais lorsqu’il s’agit de remplacer les rôles, les livrables et les événements existants par les rôles Scrum, et de les mettre en œuvre tels qu’ils sont destinés à être utilisés, c’est là que les défis émergent.

Compte tenu de mes observations personnelles sur les problèmes d’adoption de Scrum, j’ai pensé qu’il serait utile de sonder un public plus large sur l’aspect de Scrum qui a généré le plus de défis.

Au total, 35 membres de la communauté LinkedIn PMI Project, Program and Portfolio Management ont répondu au sondage avec la répartition suivante des votes :

  1. Les événements/cérémonies : 31 %
  2. Les rôles : 31 %
  3. Les livrables/artefacts : 17 %
  4. Le timeboxing de 1 à 4 semaines : 20%

Cela concorde avec ce que j’ai observé.

Bien qu’il puisse y avoir des problèmes de qualité avec les sprints et les arriérés de produits, et que les équipes immatures ne produisent pas toujours un incrément, il ne faut généralement pas trop de temps à la plupart des équipes pour se familiariser avec ces artefacts. De même, bien qu’il puisse être nécessaire d’augmenter la durée du sprint lorsque vous prenez en compte des contraintes du « monde réel » des projets non logiciels, au fil du temps, les équipes s’améliorent pour découper les éléments de travail de sorte que « quelque chose » de valeur puisse être produit en peu de temps.

Les plus grands défis que j’ai vus concernent l’adoption correcte des événements et des rôles Scrum.

Qu’il s’agisse des Daily Scrums qui se transforment en réunions de statut, de rétrospectives de sprint dangereuses psychologiquement, de revues de sprint auxquelles n’assiste aucune partie prenante externe ou de planification de sprint qui prend des jours à compléter, le but et les conditions préalables à la réussite des événements se perdent dans leur mise en œuvre.

La propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.

Alors que nous voulons tous des Product Owners fantastiques et des équipes « entières » interfonctionnelles, nous nous retrouvons avec des Product Owners qui n’ont aucun pouvoir décisionnel ou pas de temps, et une répartition imprévisible des membres de l’équipe d’un sprint à l’autre.

Aussi, lorsque nous considérons le grand nombre de conditions requises pour permettre à Scrum d’être mis en œuvre tel que conçu, la probabilité qu’elles soient toutes remplies au sein d’une organisation typique est assez faible.

Et c’est pourquoi « Scrumbut » (Scrum mais…) est la valeur par défaut, pas l’exception.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

+++++++++++++++++++++++++++

Qu’est-ce que le « Scrumbut » ?

https://www.scrum.org/resources/what-scrumbut

Les ScrumButs sont des raisons pour lesquelles les équipes ne peuvent pas tirer pleinement parti de Scrum pour résoudre leurs problèmes ni tirer pleinement parti du développement de produits à l’aide de Scrum.

Chaque rôle, règle et timebox Scrum est conçu pour fournir les bénéfices souhaités et résoudre les problèmes récurrents prévisibles.

Scrumbut – L’équipe contourne le problème plutôt que le résoudre.

ScrumBut signifie que Scrum a mis en évidence un dysfonctionnement qui contribue au problème, mais qui est trop difficile à résoudre.

Un ScrumBut conserve le problème tout en modifiant Scrum pour le rendre invisible afin que le dysfonctionnement ne soit plus une épine dans le pied de l’équipe.

Un ScrumBut a une syntaxe particulière : (ScrumBut)(Raison)(Contournement)

Exemples de ScrumBut

  • « (Nous utilisons Scrum, mais) (avoir un Daily Scrum tous les jours génère trop de frais) (donc nous n’en avons qu’un par semaine.) »
  • « (Nous utilisons Scrum, mais) (Les rétrospectives sont une perte de temps) (donc nous ne les faisons pas.) »
  • « (Nous utilisons Scrum, mais) (nous ne pouvons pas créer une fonctionnalité en un mois) (donc nos Sprints durent 6 semaines.) »
  • « (Nous utilisons Scrum, mais) (parfois nos managers nous confient des tâches spéciales) (donc nous n’avons pas toujours le temps de répondre à notre définition de Done.) »

20 façons utiles d’améliorer votre concentration dès aujourd’hui

La concentration détermine la qualité et l’orientation de votre vie.

20 Useful Ways to Create Focus Today par Dan Rockwell

https://leadershipfreak.blog/2022/02/08/the-complete-list-of-ways-to-create-focus-today/

La distraction dilue l’impact de votre vie.

Considérez la splendide absurdité d’une vie sans focus. Vous pouvez passer une journée à chasser les distractions et vous sentir important en le faisant.

Les distractions sont de tendres morceaux de plaisir qui engloutissent votre temps et gaspillent votre talent.

Le monde murmure à votre oreille mille séductions qui créent une illusion d’importance.

La concentration détermine la qualité et l’orientation de votre vie.

20 façons utiles de créer votre focus dès aujourd’hui

  1. Faites une chose à la fois. Oubliez le multitâche. Ouvrez une application. Utilisez-la. Fermez-la.
  2. Décidez de terminer ce que vous commencez. Définissez des jalons pour les tâches volumineuses.
  3. Planifiez votre temps de distraction. Donnez-vous 15 minutes pour cliquer sur les actualités avant le déjeuner, par exemple.
  4. Placez votre téléphone hors de vue et hors de portée. David Burkus appelle cela « créer des frictions » (Vidéo en fin de billet).
  5. Planifiez du temps pour terminer une tâche. Fixez une heure limite. Ensuite, observez #2 ci-dessus.
  6. Protégez vos meilleures heures. Planifiez des tâches importantes lorsque vous êtes à votre meilleur.
  7. Désencombrez votre bureau. L’encombrement crée des distractions.
  8. Planifiez des horaires pour traiter les e-mails. Si ce n’est pas l’heure de l’e-mail, désactivez-le.
  9. Gérez votre énergie. Remarquez la fatigue. Remplissez votre propre réservoir.
  10. Choisissez une ou deux tâches importantes à accomplir aujourd’hui.
  11. Allez vous promener.
  12. Dites non. Essayez.
  13. Sachez faire la différence entre urgent et important.
  14. Faites moins plaisir aux gens. Restez connecté à qui vous êtes.
  15. Mettez les gros rochers de la semaine prochaine sur votre calendrier cette semaine.
  16. Allez vous coucher. Voir #9 ci-dessus.
  17. Définissez le succès pour aujourd’hui.
  18. Communiquez avec un partenaire ou ami qui vous tienne responsable.
  19. Préparez-vous pour demain ce soir.
  20. Demandez-vous si ce que vous faites contribue réellement à votre mission.

Une extravagance d’opportunités crée de la pauvreté pour les personnes qui manquent de focus. La différence entre l’activité et la réussite est de se concentrer sur les choses qui comptent.

Ce que nous pouvons contrôler, c’est notre performance et notre exécution, et c’est ce sur quoi nous allons nous concentrer.  Bill Belichick

Laquelle de ces 20 propositions trouvez-vous le plus utile ? La plus difficile ?

Qu’est-ce qui vous aide à vous concentrer ?