Récemment, lors de notre webinaire "Les 7 péchés capitaux de la gestion de projet", nous avons appris de Justin Rowe, directeur de pratique chez notre partenaire de conseil, Lewis Fowler. Dans sa présentation, Justin a abordé les péchés de la gestion de projet ainsi que la manière de les reconnaître et de les corriger. Cela a entraîné une participation massive des participants aux questions, dont beaucoup étaient très instructives et pertinentes. Voici les réponses aux principales questions qui nous sont parvenues.
- Voyez-vous les groupes PPM souligner l'importance d'exploiter les modèles et structures de domaine existants pour une utilisation et une réutilisation par l'entreprise ?
[Je pense que c'est quelque chose qui devrait toujours être encouragé du point de vue de la gestion de projet et de portefeuille. Tout au long du cycle de vie du projet, il faut mettre l'accent sur une culture d'apprentissage et de découverte continus, car les membres de l'équipe ayant une ancienneté différente peuvent appliquer leurs connaissances du domaine aux projets au fur et à mesure de leur exécution. Il est essentiel d'appliquer à nouveau les leçons apprises dans cette situation pour saisir les changements et les fluctuations de l'activité, en particulier au niveau de l'unité commerciale. Comme les demandes de projet sont continuellement saisies et classées par ordre de priorité, l'intégration des connaissances du domaine et la structure de ce qui doit être le produit final ou la solution du projet sont des informations précieuses qui doivent être incluses dans le processus de prise de décision du projet.
Du point de vue de la gestion du portefeuille de projets, cela dépend également de la direction que prend le portefeuille par rapport à la stratégie de l'organisation et aux parties prenantes auxquelles les projets sont destinés. L'expertise du domaine doit être recueillie, communiquée et utilisée au niveau stratégique de l'organisation, en appliquant une approche équilibrée de la gouvernance du portefeuille tout en accélérant la capacité de l'équipe du projet et du portefeuille à fonctionner de manière hautement efficace et efficiente. Comme je l'ai mentionné pendant le webinaire, permettre à l'équipe PPM de s'intégrer à sa base de clients, ainsi qu'aux zones de parties prenantes, peut augmenter l'expertise du domaine afin de garantir qu'elle se concentre sur la conduite des résultats attendus du projet tout en gérant tous les domaines du projet (portée, calendrier, budget, risque, etc.). De cette façon, l'équipe PPM dispose d'un aperçu supplémentaire et d'une conscience situationnelle de l'état de son projet, tout en capturant davantage de données quantitatives dans son outil PPM utilisé.
- Où se situe un bureau de gestion de programme dans la hiérarchie des bureaux de gestion de portefeuille/projet ? Mon organisation cherche à normaliser les PMO départementaux, à établir des politiques, une gouvernance, etc.
D'après mon expérience, l'établissement d'un bureau de gestion de programme dépend de quelques circonstances, mais relève toujours de la ou des situations elles-mêmes. Tout d'abord, la désignation de la création d'un bureau de gestion de programme formel est liée à de multiples facteurs plus stratégiques, notamment la taille et la complexité des projets au sein du portefeuille, la structure de gouvernance requise pour l'activer et la manière dont elle s'aligne financièrement sur l'organisation. La complexité accrue du nombre de projets et la façon dont elle affecte la planification et l'exécution budgétaires de l'entreprise peuvent être utilisées pour déterminer si un programme doit être établi avec un bureau de gestion de programme. Au fur et à mesure de l'exécution des projets, les budgets individuels au sein de chaque projet sont gérés, le montant total pouvant se chiffrer en centaines de milliers, par exemple, alors que dans le cas d'un programme comportant plusieurs projets stratégiquement liés et alignés sur le développement d'un produit plus important, le montant peut se chiffrer en centaines de millions. En outre, s'il existe un besoin accru de structure et de gouvernance au sein du portefeuille de projets, cela pourrait également être utilisé comme contribution au potentiel d'un bureau de gestion de programme. Il y a beaucoup d'autres événements situationnels qui devraient avoir lieu pour déterminer le véritable "besoin par rapport à la volonté" autour d'un bureau de gestion de programme. Mais voici quelques questions auxquelles vous devez réfléchir...
- Y a-t-il plusieurs projets dont la portée n'est pas nécessairement similaire, mais qui soutiennent le développement d'un produit ou d'une solution globale ?
- Y a-t-il plusieurs projets dont les budgets sont fiscalement liés et qui mènent au développement du même produit ou de la même solution ?
- Existe-t-il une exigence pour la gestion de plusieurs projets étroitement liés avec des avantages connexes qui s'alignent sur un but et/ou un objectif de niveau stratégique ?
- Est-il nécessaire d'assurer une gouvernance de niveau stratégique de plusieurs projets où les ressources, les dépendances et autres variables liées au projet sont étroitement alignées ?
La réponse à certaines de ces questions pourrait fournir une première orientation sur le besoin potentiel d'établir des programmes ainsi qu'un bureau de gestion des programmes. Par ailleurs, le document du PMI Standard For Program Management, Third Edition est un excellent point de référence qui peut également apporter un éclairage à votre question.
- Voyez-vous des PMO utiliser des outils de planification Kanban pour gérer le travail de développement (itérations et Scrums, par exemple) ?
Dans le cadre des projets de développement, en supposant que cette question vise le développement de logiciels, l'utilisation de Kanban est excellente pour visualiser la progression ainsi que pour voir où pourraient se trouver les problèmes. Grâce à l'agilité continue qui est ancrée dans cette méthodologie, l'utilisation de Kanban peut également être appliquée aux PMO, qu'ils soutiennent ou non une fonction informatique ou qu'ils ne soient pas du tout liés à l'informatique. Avec Kanban, l'accent est mis ici sur la compréhension et la visualisation du flux de travail, la vitesse à laquelle les tâches sont exécutées et la capacité à identifier les problèmes pour lesquels des solutions sont immédiatement découvertes afin de soutenir l'apprentissage continu. En outre, l'équipe peut appliquer des limites de travail en cours qui plafonnent la capacité des tâches qu'une personne peut effectuer afin de garantir la livraison continue de logiciels.
En ce qui concerne l'ordonnancement, l'application des leçons tirées des limitations de capacité des projets précédents ou des itérations du projet actuel permettra à l'ordonnancement de rester agile, sans pour autant entraver l'avancement du projet. L'application des méthodes Scrum telles que les sprints (périodes de temps fixes, 2 semaines par exemple) avec Kanban peut également être utilisée pour définir des mesures autour de la performance et de la vélocité, mais des temps de cycle dans des tâches spécifiques qui ont des entrées-sorties définies. La flexibilité et l'utilisation des deux méthodes doivent être définies, en fonction de l'environnement de développement et de la situation qui correspond le mieux à la capacité de l'équipe de développement à réaliser des performances efficaces.
