Étiquette : scope

Pouvez-vous tirer parti du timeboxing si votre projet utilise une approche prédictive dites « en cascade » ?

Le par mopertodans outils et méthodes2 commentaires

Voici les principes que vous pouvez suivre pour tirer parti du timeboxing dans les projets en cascade (ou toute autre approche projet).

What About Timeboxing a Waterfall Project?  par Bonnie Biafore

https://www.bonniebiafore.com/what-about-timeboxing-a-waterfall-project/

Le timeboxing est une approche puissante d’Agile. Plutôt que de rendre le périmètre de contenu (la portée) statique, vous fixez le temps et les ressources et vous modifiez la portée pour obtenir la valeur maximale en un minimum de temps et de coûts. Au lieu d’estimer la durée de la tâche, vous utilisez des blocs de temps fixes et ajustez la portée en conséquence.

Voici les principes que vous pouvez suivre pour tirer parti du timeboxing dans les projets en cascade.

Principe 1 : Décomposez les phases en petits morceaux.

Au lieu de traiter chaque phase de cascade comme un grand bloc monolithique, divisez-la en morceaux plus petits et gérables. Par exemple, collectez les exigences pour un secteur de l’entreprise dans un bloc de temps de deux semaines, un deuxième domaine dans le bloc de temps des deux semaines suivantes, etc. Dans chaque bloc de temps, hiérarchisez les zones de collecte des exigences à l’aide de paramètres tels que l’importance et la complexité.

Principe 2 : Ajouter un tampon entre les blocs de temps (timebox).

Incluez de petits blocs de temps tampon dans l’échéancier du projet. Cela donne le temps de réfléchir, d’apprendre et de planifier la portée à aborder dans les prochains blocs de temps. De plus, en vous concentrant sur des zones de tâches plus petites et en prenant le temps d’apprendre et de hiérarchiser les deux, vous vous assurez de travailler sur les éléments les plus importants de la phase. (Dans cet exemple, les exigences les plus importantes.)

Principe 3 : Ajustez la portée, pas la durée.

Si une tâche ou un ensemble de tâches n’est pas terminé dans son bloc de temps, ajustez la portée ou déplacez les éléments moins prioritaires vers un bloc de temps ultérieur au lieu de prolonger les délais. Par exemple, lors de la planification détaillée, concentrez-vous d’abord sur les domaines jugés les plus importants par les parties prenantes du projet et reportez la planification détaillée pour les éléments moins importants à des blocs de temps ultérieurs. Si l’échéancier de la phase de planification devient trop long, cessez de planifier et avancez avec le projet avec une portée réduite (les tâches les plus importantes).

Principe 4 : Plusieurs sous-équipes travaillent en parallèle, chacune pour une durée prédéterminée.

Une fois que les membres de l’équipe se sont habitués à travailler dans des blocs de temps, plusieurs équipes peuvent travailler en parallèle sur leurs propres tâches jusqu’à ce que la phase en cascade soit considérée comme terminée. C’est en ceci que les blocs de temps diffèrent des sprints en agile. Les blocs de temps n’ont pas besoin de livrer un produit utilisable, comme les sprints. Étant donné que les projets en cascade impliquent souvent une portée plus grande que les projets agiles, de nombreuses sous-équipes de projet peuvent travailler en parallèle. La nécessité d’une validation fréquente de la part du management, vitale pour l’agilité, n’est peut-être pas nécessaire. Dans un environnement en cascade, plusieurs équipes peuvent progresser sans cette contrainte, car elles ne prennent pas fréquemment de décisions vitales pour l’entreprise. Pourtant, elles tirent toujours parti de la portée ciblée et de courts et périodiques temps de réflexion et d’apprentissage.

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

Profitez de l’approche par bloc de temps à chaque phase de la cascade. Les exigences et la planification peuvent être décomposées et attribuées à des sous-équipes travaillant dans des blocs de temps. L’étape de construction est également idéale pour ce concept : Le travail sur les processus métiers, les différents outils et la documentation peuvent être attribués à des équipes travaillant en parallèle. Les tests peuvent fonctionner de la même manière, avec des sous-équipes testant divers domaines ou sous-produits avant une session de test finale pour valider l’ensemble des livrables du projet.

Regardez l’un de vos projets passés ou votre projet actuel et réfléchissez à la façon dont vous pourriez le mener avec des blocs de temps. Réfléchissez à la manière dont vous pourriez avoir besoin de modifier d’autres processus tels que la communication et le reporting lorsque vous avez des sous-équipes travaillant simultanément.

Pour en savoir plus sur le timeboxing, consultez la formation Agile Foundations de Doug Rose.

_______________________________________

Cet article fait partie de la série de bulletins d’information Bonnie’s Project Pointers, qui compte plus de 78 000 abonnés. Cette newsletter est rédigée en anglais à 100% par un humain (pas d’extraterrestres ou d’IA impliqués). Si vous aimez cet article, vous pouvez  vous abonner pour recevoir des notifications lorsqu’un nouvel article est publié.

 

Dérive des fonctionnalités

Le par mopertodans experience sharingLaisser un commentaire

Bien que nous ne disions pas facilement non à une demande de nouvelle fonctionnalité, ce serait parfois la bonne chose à dire.

Feature creep par Seth Godin

https://seths.blog/2022/09/feature-creep/

  1. L’ajout d’une autre fonctionnalité est bon marché par rapport aux bénéfices qu’elle offre aux nouveaux utilisateurs ou aux utilisateurs existants.
  2. Une fois qu’une fonctionnalité est ajoutée, elle n’est presque jamais supprimée.
  3. Lorsque suffisamment de fonctionnalités sont ajoutées, le système tombe en panne et échoue.

Il ne s’agit pas seulement de développement logiciel. C’est le menu du restaurant. Ce sont les boutons sur le tableau de bord d’une voiture. C’est la variété de choix qui s’offrent aux parents quant aux dates de début ou de fin de camps de vacances. Tout ce qui demande beaucoup de travail acharné peut être légèrement amélioré simplement en ajoutant une option inoffensive.

À un moment donné, Yahoo avait 183 liens sur sa page d’accueil. Google, qui en avait deux, s’est finalement emparé de tout son trafic de recherche. L’application sur mon téléphone peut maintenant ouvrir le coffre de ma voiture si j’appuie sur suffisamment de boutons.

Les fonctionnalités sont utiles (c’est pourquoi nous les appelons fonctionnalités). Et oui, il est important de servir les personnes mal desservies et invisibles. Mais les ajouts ne peuvent pas continuer éternellement. À un moment donné, il y a faillite du système et le cycle recommence.

Bien que nous ne disions pas facilement non à une nouvelle fonctionnalité, nous pouvons être intelligents et proactifs lorsque vient le temps d’effacer l’ardoise et de recommencer.

Y-a-t-il des avantages à avoir un Product Owner sur un projet CRM ? par Mohamed Michael Kazak

Le par mopertodans agile, experience sharingLaisser un commentaire

La réponse courte est OUI !

Les projets CRM sont complexes et nécessitent un Product Owner dédié et compétent pour assurer leur succès. Un Product Owner est chargé de combler le fossé entre les besoins de l’entreprise et les équipes de développement, tout en optimisant le système pour réussir.

Laissez-moi vous parler des avantages à avoir un Product Owner sur un projet CRM.

Comprendre les besoins et les exigences de l’entreprise

Le Product Owner travaille en étroite collaboration avec les utilisateurs et les parties prenantes pour comprendre leurs besoins et leurs exigences. En cartographiant les processus métier et les parcours des utilisateurs, le Product Owner comprend mieux comment le CRM peut être adapté pour répondre aux besoins spécifiques de l’entreprise. Cela permet de s’assurer que le système est conçu et construit de manière à s’aligner sur les processus métier et les besoins des utilisateurs, tout en offrant une réelle valeur ajoutée.

Guider le processus de développement

Une fois les processus métier définis, le product owner collabore avec l’équipe de développement pour concevoir et mettre en œuvre la solution CRM. Cela implique de définir les histoires et les exigences des utilisateurs, de hiérarchiser les fonctionnalités en fonction de la valeur business et de travailler en étroite collaboration avec l’équipe de développement pour s’assurer que le système est conçu et construit d’une manière qui s’aligne sur les processus métier et les besoins des utilisateurs. Tout au long du processus de développement, le Product Owner fournit des conseils et des commentaires pour s’assurer que le système répond aux exigences qui ont été définies avec les utilisateurs et les parties prenantes.

Trouver l’équilibre entre les besoins de l’entreprise et la convivialité

Trouver le bon équilibre entre les besoins des uns et des autres.

L’un des rôles les plus importants du Product Owner est d’équilibrer les besoins de l’entreprise avec les besoins des utilisateurs. Bien que le Product Owner soit chargé de s’assurer que le système répond aux besoins de l’entreprise et apporte une réelle valeur ajoutée, il donne également la priorité à la facilité d’utilisation pour s’assurer que le système est intuitif et facile à utiliser pour les utilisateurs.

Cet équilibre entre les besoins de l’entreprise et la facilité d’utilisation peut parfois être un défi.

Par exemple, une entreprise peut exiger que certaines données soient saisies dans un certain format à des fins de reporting, tandis que les utilisateurs peuvent trouver ce format fastidieux et long à utiliser. Le product owner doit travailler à la fois avec l’entreprise et les utilisateurs pour trouver une solution qui réponde aux besoins de chacun. Il peut s’agir de trouver un compromis satisfaisant pour les deux parties, ou de trouver une solution de contournement qui répond aux exigences de l’entreprise tout en facilitant la saisie des données par les utilisateurs.

Communiquer avec les parties prenantes

En plus de travailler avec l’équipe de développement, le Product Owner communique régulièrement avec les parties prenantes de l’entreprise. Il s’agit notamment de fournir des mises à jour sur l’état d’avancement du projet, de solliciter des commentaires sur les conceptions et les fonctionnalités, et de s’assurer que le système répond aux besoins de toutes les parties prenantes. Cela permet de s’assurer que toutes les personnes impliquées dans le projet sont tenues au courant et ont leur mot à dire dans le processus de développement.

Assurer le succès du lancement et de l’adoption

Enfin, le Product Owner est responsable de s’assurer que le CRM est lancé et adopté avec succès par l’entreprise. Il s’agit de contribuer à des activités de formation et de soutien aux utilisateurs afin de s’assurer qu’ils sont à l’aise avec le nouveau système et qu’ils sont en mesure de tirer pleinement parti de ses capacités. En optimisant le système pour qu’il réussisse et en comblant le fossé entre les besoins de l’entreprise et le développement, le propriétaire du produit peut assurer le succès du projet CRM.

En conclusion, avoir un Product Owner sur un projet CRM offre de nombreux avantages.

Le Product Owner apporte la plus grande valeur possible, aussi rapidement que possible.

Un Product Owner s’assure que le système répond aux besoins de l’entreprise et apporte une réelle valeur, fournit des conseils et des commentaires tout au long du processus de développement, équilibre les besoins de l’entreprise avec les besoins des utilisateurs, communique régulièrement avec les parties prenantes et veille à ce que le système soit lancé et adopté avec succès par l’entreprise.

Si vous vous lancez dans un projet CRM, il est essentiel d’investir dans un Product Owner solide et expérimenté pour en assurer le succès.

Mohamed Michael Kazak

 

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.

Précédents billets de Mohamed Michael Kazak

Comment tirer parti de votre énoncé de portée de projet, en particulier ce qui est hors périmètre ?

Le par mopertodans experience sharingLaisser un commentaire

L’énoncé de portée de votre projet peut être le document le plus important que vous produisiez en tant que manager de projet. Il définit ce que le projet va livrer, comment en mesurer les bénéfices… et peut-être plus important encore ce que le projet ne va pas faire !

How to Leverage Your Out-of-Scope Statement par Bonnie Biafore

https://www.bonniebiafore.com/how-to-leverage-your-out-of-scope-statement/

L’énoncé de portée de votre projet peut être le document le plus important que vous produisiez en tant que chef de projet. Il aide à définir le projet, à saisir ce que le projet produira et il définit les critères de réussite pour ces résultats. Une section cruciale de l’énoncé de portée ne couvre pas du tout ce qui est dans le périmètre : Cette section spécifie ce qui est hors périmètre (i.e. ce que le projet ne fera pas).

Voici quelques conseils pour tirer le meilleur parti de la section hors périmètre de votre énoncé de portée.

Réalité d’exécution

Comprenez quelles sont les réalités business.

Assurez-vous qu’elle reflète les réalités de l’exécution du projet. Dans l’énoncé de la portée, précisez ce qui est dans et hors du périmètre. Dans la section hors périmètre, veillez à documenter pourquoi les éléments hors périmètre sont exclus. En règle générale, les éléments hors périmètre sont dictés par les délais de livraison, la complexité ou la disponibilité de l’expertise. Parfois, les priorités business peuvent exclure certains éléments.

Bénéfices

Les bons « petits » projets peuvent rapporter gros.

Expliquez les bénéfices d’une portée plus petite. Une portée réduite permet de focaliser les efforts, de manager une équipe plus petite, de réduire les coûts et de réduire le besoin d’intégration. Ceux-ci réduisent la complexité et augmentent la probabilité de réussite du projet. Si la portée réduite inquiète les principaux intervenants, créez des profils de risque pour la portée réduite proposée et un profil pour la plus large que les intervenants pourraient rechercher. Les différences de risque pourraient vous aider à justifier d’aller de l’avant avec une portée plus petite.

Débat

Déclenchez le débat, si nécessaire. En ce qui concerne la portée du projet, les pires débats sont ceux qui doivent avoir lieu, mais qui ne le font pas. Documenter succinctement ce qui est dans et hors du périmètre est susceptible de générer un débat entre les principales parties prenantes. C’est bon parce que c’est probablement nécessaire pour faire avancer votre projet. N’oubliez pas que votre travail en tant que manager de projet consiste à évaluer les risques et la faisabilité. Donc, votre rôle dans le débat est d’informer les parties prenantes, pas de choisir un camp !

Perspective

Approche MVP

Partagez à quoi pourrait ressembler une « Phase 2 ». Lorsqu’un projet individuel se termine, cela ne signifie pas nécessairement que la création de valeur business prend fin. Dans la pratique, de nombreuses initiatives de projets impliquent une série de projets, chacun apportant une valeur ajoutée. En fait, c’est la prémisse des méthodologies de projet agiles. Notez dans votre section hors périmètre à quoi pourrait ressembler un projet futur, comme une phase 2. Cela peut faciliter l’approbation de votre énoncé de portée par les parties prenantes.

Avez-vous utilisé la section hors périmètre d’autres façons ? Cette section vous a-t-elle causé des ennuis ou sauvé votre projet de problèmes ?

Pour en savoir plus sur la portée, consultez le cours de Bonnie Project Management Foundations.

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

Le par mopertodans agileLaisser un commentaire

Pour de nombreux professionnels de projet, la gestion d’un arriéré d‘histoires 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.

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

Le par mopertodans experience sharingLaisser un commentaire

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:

 

Dans les délais prévus

Le par mopertodans agile, best practicesLaisser un commentaire

Quels sont les bénéfices à avoir des délais bien définis ?

On schedule par Seth Godin

https://seths.blog/2022/01/on-schedule/

Nous tirons un énorme avantage de prendre un engagement simple :

Nous respectons les délais.

L’avantage est qu’une fois que nous avons convenu de la date limite, nous n’avons plus à nous en soucier. Nous n’avons pas à négocier, à trouver des excuses ni même à stresser à ce sujet.

Il ne sera pas livré quand il sera parfait.

Il sera livré quand nous avons dit qu’il le serait.

Une fois que ceci est clair, la qualité de ce que nous expédions augmente grandement. Au lieu de passer du temps et de l’énergie à chercher des raisons, des excuses ou à être dans le déni, nous faisons simplement le travail.

Et au fil du temps, nous estimons de mieux en mieux les délais sur lesquels nous engager. Parce que si nous promettons, nous livrons.

Selon moi, comme avec l’approche Agile, les délais et les moyens sont fixés au départ, la variable d’ajustement devient le contenu et surtout la priorisation de ce contenu en fonction de sa valeur business et de la capacité de l’équipe à livrer.

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

Le par mopertodans experience sharing, leadershipLaisser un commentaire

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 ».

Avantages moins connus du management du périmètre et contenu de projet

Le par mopertodans best practices, outils et méthodesLaisser un commentaire

Le management du contenu consiste à s’assurer que votre projet produit ce qui est nécessaire et seulement ce qui est nécessaire pour atteindre les objectifs du projet.

Less Well-Known Benefits of Scope Management par Bonnie Biafore

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

Le management du contenu offre également des bénéfices supplémentaires dont vous entendez rarement parler.

Vous aidez à manager les risques.

Livre sur Amazon

Parlez à un chef de projet expérimenté et vous entendrez probablement une leçon durement apprise : Plus votre projet est grand, plus il devient risqué. Pour les initiatives qui nécessitent beaucoup de changements organisationnels et de livrables de projet, vous pouvez découper le périmètre et contenus en phases pour rendre les choses plus faciles à manager. Cette décomposition en morceaux plus petits réduit les risques et facilite l’absorption des changements par l’organisation, car ils sont appliqués par étapes progressives. À bien des égards, la façon la plus efficace de manager les risques d’un projet est de travailler en étroite collaboration avec vos parties prenantes pour gérer la portée.

Vous élargissez la compréhension des exigences de l’entreprise.

Le management du périmètre est mieux effectué par la discussion. Et la discussion aide non seulement l’équipe de projet à comprendre les besoins de l’entreprise, mais aide également l’entreprise à reconnaître ce qui est simple et ce qui est difficile à produire pour l’équipe projet.

De plus, une bonne gestion du contenu implique de hiérarchiser les exigences. Cela aide l’équipe projet à comprendre ce qui est vital pour l’entreprise et cela peut aussi améliorer la perspective de l’entreprise sur ses propres besoins ! Ainsi, l’entreprise et l’équipe projet sont mieux placées pour produire ce qui est le plus important, réduisant la portée et les risques.

Vous renforcez la confiance dans le projet.

Des conversations détaillées sur les contenus, y compris des questions bien réfléchies pour mieux comprendre les besoins opérationnels, peuvent aider à renforcer la confiance des parties prenantes dans la capacité de l’équipe projet à atteindre ses objectifs. Les bonnes questions qui inspirent l’analyse et la compréhension des besoins de l’entreprise peuvent renforcer la confiance : L’équipe projet sait ce qui doit être fait. Et démarrer un projet avec la confiance des parties prenantes de l’entreprise est un gros plus.

Vous vous adaptez aux ressources disponibles.

Les pénuries de compétences sont partout présentes et ont été amplifiées par les impacts de la pandémie Covid. Le management du périmètre et contenus aide tout le monde à être réaliste quant à ce qui peut et ne peut pas être fait. Les discussions sur les compétences disponibles aident à élaborer un échéancier de projet réaliste. La portée et la gestion des ressources favorisent des discussions productives sur la hiérarchisation des travaux, en particulier pour les ressources rares. Plus tôt ces conversations et hiérarchisations sont faites et comprises, plus il sera facile d’établir un planning robuste et de progresser tout au long du cycle de vie du projet.

Avez-vous observé d’autres bénéfices du management de la portée du projet ?

Si c’est le cas, partagez-les avec nous !

Pour en savoir plus sur Le management du périmètre et contenus, consultez le cours de Bonnie : Project Management Foundations.

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

TOP 3 d’Août 2022 sur DantotsuPM, le blog du management de projets

Le par mopertodans pointeurs utilesLaisser un commentaire

Je profite de la trêve de fin d’année pour vous remercier d’avoir particulièrement apprécié ces billets.

L’intelligence émotionnelle : un atout pour les managers de projets comme pour tout autre leader

Qui n’a jamais entendu les phrases :

Les émotions n’ont pas leur place dans le monde professionnel !

ou encore

Quand on vient au bureau, on laisse ses émotions à la maison.

Avez-vous lu ce rapport sur l’état du coaching agile : « 2022 State of Agile Coaching Report » ?

Téléchargez le document

Riche des données de plus de 2 000 coachs agiles professionnels qui ont partagé leurs expériences sur l’impact du coaching agile, le deuxième rapport annuel sur l’état du coaching agile est publié. Le rapport couvre un éventail de sujets liés au coaching agile dans le monde réel, y compris le retour sur investissement, la valeur et les métriques permettant de définir le succès.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

15 avantages que vous apporte le management de projet  

Et vous, en tant que manager de projet, dirigez et menez et vous assurez que l’organisation tire le plein avantage de tout ce que vous faites. Cela vous rend extrêmement précieux pour toute organisation avec laquelle vous travaillez. Du niveau de l’équipe jusqu’au comité exécutif où ils examinent les résultats et les impacts business. Soyez fier de vous. Vous êtes manager de projet.

Comment faire face à une réduction du budget de votre projet ?

Le par mopertodans best practices, experience sharingLaisser un commentaire

La dynamique des affaires pourrait conduire à une réduction du budget de votre projet. Bien qu’elle soit perturbatrice et déclenche des émotions, la situation n’est pas impossible à manager.

Dealing with a Project Budget Cut par Bonnie Biafore

http://www.bonniebiafore.com/dealing-with-a-project-budget-cut/

La dynamique des affaires pourrait conduire à une réduction du budget de votre projet.

Bien qu’elle soit perturbatrice et déclenche des émotions, la situation n’est pas impossible à manager.

Voici des conseils pour faire face à une réduction budgétaire.

Restez calme.

Vous pourriez interpréter une réduction budgétaire comme un échec.

Une réduction budgétaire est une décision business, qui nécessite une réponse bien réfléchie.

Continuez à mener votre équipe comme si le projet était toujours viable… parce que c’est le cas.

Comprenez la raison d’être de la coupe.

les 5 pourquoi, les 5 whys
Utilisez la technique des 5 pourquoi (relisez ce billet)

Vous devez comprendre ce qui a déclenché la réduction budgétaire pour comprendre comment y répondre.

Discutez de la coupe avec votre sponsor pour comprendre son cheminement de pensée.

Des réponses différentes sont requises lorsqu’une réduction est due à une réduction des coûts à l’échelle de l’entreprise, par rapport à quelque chose lié à votre approche de management de projet ou à un livrable de votre projet dont la priorité a changé.

Examinez les priorités du projet.

Le projet a encore des attentes à satisfaire et des résultats à atteindre. Affirmez ces attentes et comparez-les à ce que le budget réduit permettra de faire. Examinez les priorités des exigences du projet et modifiez-les au besoin. Réexaminez l’analyse de rentabilité du projet pour faciliter votre priorisation. Si vous n’avez pas hiérarchisé vos besoins, commencez par ceci, puis déterminez ce que vous pouvez offrir avec votre budget réduit.

Recherchez des approches de réduction des coûts.

La réduction des heures des ressources externes, la réduction des caractéristiques supplémentaires du produit et la réduction des exigences risquées (et donc coûteuses) sont des moyens potentiels de réduire le coût global du projet. Créez une liste complète d’options pour revue avec la direction. Lorsque la direction décide des mesures de réduction des coûts à prendre, modifiez et affinez votre plan de projet en conséquence.

Communiquez !

Communiquez de manière ouverte à tous les niveaux

Dites à votre commanditaire et aux principales parties prenantes ce que le nouveau budget du projet peut permettre. Négociez pour trouver la meilleure approche et aligner les attentes. Partagez les nouvelles attentes et le plan de projet révisé avec votre équipe de projet. Insistez sur le fait que le projet continuera d’aller de l’avant. Pour maintenir le moral de l’équipe, discutez des résultats opérationnels que le projet peut produire. Pour plus de motivation, demandez à votre sponsor de communiquer également ce message.

Avez-vous déjà fait face à une réduction budgétaire dans un projet ?

Quelles émotions cela a-t-il induit chez vous et votre équipe ?

Quelles mesures avez-vous prises pour « vous débarrasser » de ces sentiments et réfléchir à la façon d’aller de l’avant ?

Pour en savoir plus sur les budgets de projet, consultez la formation Bob McGannon’s Project Management Foundations: Budgets

 

La mort de la dérive de contenu (le « scope creep ») et le management de projet Agile

Le par mopertodans agile, best practicesLaisser un commentaire

Un seul mot, adaptabilité, résume les avantages du management de projet agile de la manière la plus brève et la plus directe possible.

The Death of Scope Creep  – Agile Project Management

https://www.projectsmart.co.uk/scope-management/the-death-of-scope-creep-agile-project-management.php  par Duncan Haughey

Un seul mot, adaptabilité, résume les avantages du management de projet agile de la manière la plus brève et la plus directe possible. Les organisations qui adoptent l’agilité, qui s’équipent pour s’adapter, sont mieux préparées à s’adapter rapidement aux évolutions fréquentes du marché et aux besoins des clients.

Cependant, d’après mon expérience, la flexibilité de l’agilité peut être une arme à double tranchant. Lorsque vous avez beaucoup trop de latitude sans définitions explicites, la dérive de contenu se produit. Et si vous ne contrôlez pas ce glissement du périmètre, vous vous retrouverez avec des membres de l’équipe fatigués, des clients mécontents et une initiative qui a déraillé !

Qu’est-ce qui motive la dérive de contenu dans les projets agiles ?

Et plus important encore, comment pouvez-vous l’empêcher de mettre en danger vos projets ?

Continuez à lire ce billet pour le savoir.

À quoi ressemble le Scope Creep et comment pouvez-vous le repérer ?

La dérive de contenu se produit lorsque les besoins, les objectifs ou les buts d’un projet changent bien au-delà de ce qui a été promis à l’origine. Chaque fois que ce changement se produit, le projet n’est plus strictement décrit. Et pire encore, les limites des attendus et finalement de la fin du projet deviennent floues.

Savoir à quoi ressemble le scope creep n’aide que si vous savez comment le repérer, et il existe plusieurs façons de le faire. Peut-être introduisez-vous progressivement des choses mineures. Peut-être que les délais sont ignorés. Les délais manqués peuvent amener les membres de l’équipe à mal comprendre leurs devoirs et obligations. Peut-être que votre analyste d’affaires est moins directement engagé.

Si vous apercevez de tels signes, la dérive de contenu met probablement en danger votre projet.

Qu’est-ce que la dérive de contenu et le management de projet agile ?

Dans le management de projet agile, la dérive de contenu fait généralement référence à des changements réguliers, mais non approuvés et non planifiés, qui ont un impact négatif sur les limites du projet. Généralement, en pratique, de tels scénarios signifient que vous mettez constamment en œuvre des changements sans tenir compte de la façon dont le projet en est impacté.

Comment reconnaître cette dynamique ?

Eh bien, ce glissement se manifeste le plus souvent avec l’ajout de nouvelles fonctionnalités et services aux produits. Et cela se produit surtout lorsque de tels ajouts sont effectués sans tenir compte de l’effet sur d’autres limites du projet (par exemple : les délais, le budget, le personnel, la qualité, la sécurité, etc.).

Donc, beaucoup d’entre nous, y compris moi-même, sont conscients du concept de triple contrainte dans le management de projet : Si le contenu d’un projet change, cela peut en affecter la durée et / ou les coûts. Si les effets sur les délais et le budget ne sont pas pris en compte, la qualité va en souffrir. Et c’est ainsi que vous obtenez une dérive de contenu dans le management de projet agile.

Comment éviter que la flexibilité agile ne provoque de dérive de contenu

Pour éviter le glissement de portée associé à la flexibilité requise avec l’agilité, créez votre processus de contrôle des modifications à l’aide d’un tableau Kanban. Une flexibilité incontrôlée peut éventuellement entraîner une dérive de contenu et détourner le projet de son plan initial. Même si votre portée est flexible, restez constamment aligné avec votre plan.

Comment ? Utilisez le nettoyage du backlog (backlog grooming), également connu sous le nom de SCRUM refinement. Cette activité importante est trop souvent négligée.

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile
Le nettoyage du backlog doit être effectué une fois par sprint et implique les éléments suivants
  • Ajout de critères, de contexte, d’urgence, d’estimations ou d’éléments narratifs aux éléments du backlog avant de les pousser vers la production dans un cycle.
  • Suppression des éléments inutiles qui n’offrent plus de sens pour le projet.
  • Harmoniser les objectifs avec la vision pour maintenir un bon périmètre.

Il est essentiel de prendre ces mesures pour minimiser ou prévenir la dérive de contenu. En fin de compte, le nettoyage du backlog permet aux équipes d’accélérer la planification des sprints et d’améliorer l’allocation et la décomposition du travail. Le processus permet essentiellement à un système efficace de management du changement de prendre effet tout en maintenant la flexibilité souhaitée.

Impliquez tous les membres de l’équipe de projet et atténuez les causes du scope creep

Pour éviter la dérive de contenu, impliquez tous les membres de l’équipe. Cela signifie que, même lorsque vos parties prenantes sont satisfaites, n’oubliez pas de vérifier que vos développeurs sont également satisfaits. Informez-les du processus de management des changements et de la façon dont cela les affectera. Ils doivent être des gardiens, des garants de la portée du projet, plutôt que des acteurs du changement.

Gardez également à l’esprit que les membres de l’équipe projet, du moins d’après mon expérience, aiment aider et peuvent accepter d’apporter de gros changements sans passer par la procédure de management des changements.

Pour éviter cela, précisez que tout le monde ne devrait pas accepter d’apporter des modifications à moins d’y être autorisé pour éviter de perturber le calendrier du projet et potentiellement créer une dérive de contenu. Tout membre de l’équipe qui souhaite aider les intervenants doit décrire la procédure de contrôle des changements et se porter volontaire pour aider à enregistrer la demande de changement.

Pourquoi est-il si important d’être si vigilant ?

C’est une question à laquelle il est facile de répondre : la dérive de contenu est un sérieux problème dans les projets agiles, en particulier lorsque le manager de projet, les équipes et les partenaires n’apprécient pas l’effet que les changements peuvent avoir sur l’équipe, le budget et les délais. Heureusement, si vous êtes explicite sur la portée initiale du projet et que vous gérez correctement les modifications apportées à votre plan de projet tout au long de la durée de vie du projet, il est peu probable que la dérive de contenu soit un problème majeur.

Mais pour en être certain, vous aurez toujours besoin d’un système de management de projet efficace qui soit à la hauteur du défi, alors utilisez des outils de management des changements qui vous permettent de documenter de nouvelles modifications et d’évaluer instantanément l’impact de ces modifications.

En tant que manager de projet, vous pouvez hiérarchiser ces modifications et allouer les tâches aux membres de l’équipe à l’aide de solutions telles que ProjectManager. Ensuite, une fois qu’un changement est autorisé, quelqu’un peut s’y atteler immédiatement.

Mettez en œuvre des procédures de management des changements

Que se passe-t-il lorsque quelqu’un essaie d’apporter des changements ? Selon mon expérience, il est naïf de croire que rien ne changera. Mais tous les changements ne sont pas mauvais. Un changement structuré, bien géré et approuvé dans vos projets est tout ce dont vous avez besoin pour éviter la dérive de contenu.

Pour cultiver de tels changements, vous voudrez utiliser une stratégie de management des changements pour décrire les processus de contrôle du changement qui doivent être mis en œuvre et quand le plan de projet doit être mis à jour.

Il est également essentiel de mettre en place une procédure de management des risques qui spécifie la fréquence à laquelle le statut global de votre projet sera évalué. Cette étape vous permet de tenir à jour le registre des risques dont la dérive de contenu.

Et le processus n’a pas besoin d’être intimidant : une procédure de gestion des changements est simple. Fondamentalement, quelqu’un propose un changement via une demande qui est ensuite examinée, acceptée ou refusée. Si elle est acceptée, le changement est inclus dans le plan du projet. L’utilisation des fonctionnalités de management des changements fournies par votre outil de gestion de projet facilitera ce processus.

En fait, l’établissement des mesures correctives implique de déterminer qui évaluera et approuvera les changements car, sans méthode, le changement se produit sans prévenir.

Évitez les changements de DERNIÈRE MINUTE

Enfin, pour éviter toute dérive de contenu, évitez tout changement de dernière minute. Commencez par déterminer la portée de votre projet en fonction des besoins de vos parties prenantes. Ensuite, à l’aide d’une structure de répartition du travail (WBS), générez un plan de travail complet. Le plan de travail est la conséquence de savoir ce que votre projet apportera. Dans le plan, incluez tous les besoins et la façon dont vous y répondrez sous forme d’activités, d’événements et d’objectifs.

Pour vous assurer que vous n’avez rien négligé, faites le lien entre l’échéancier de votre projet et votre processus de management des besoins.

Conclusion & à retenir

Quel que soit le projet, l’évolution des besoins est considérée comme un échec de planification dans le management de projet conventionnel. Aussi, votre étape de planification initiale doit-elle être solide comme le roc, surtout si vous voulez éviter la dérive de contenu.

Si vous ignorez la dérive et n’essayez pas de l’empêcher de se produire en premier lieu, vous risquez de mener votre projet à l’échec et personne ne souhaite cela !

Comment contrôlez-vous la portée de vos projets ?

15 avantages que vous apporte le management de projet (les 15 + conclusion)

Le par mopertodans experience sharingLaisser un commentaire

Le management de projet offre de considérables avantages et bénéfices aux organisations qui ont besoin de livrer des solutions.

Benefits of Project Management par Leigh Espy

#1 – Propriété claire pour la réussite du projet

Les projets reposent sur de nombreuses personnes travaillant vers un objectif commun. Mais le projet et l’équipe ont besoin d’un leader pour faire avancer le projet et adopter une vision plus large.

Les membres de l’équipe examinent leurs responsabilités individuelles d’un point de vue étroit. Mais le/la manager de projet prend en charge l’ensemble du projet. Il ou elle travaille au sein des équipes pour résoudre les problèmes, suivre les jalons et maintenir le projet sur la bonne voie.

#2 – Organisation et planification

Le/la manager de projet travaille avec l’équipe pour créer des échéanciers, des budgets et d’autres composants du plan de projet.

Cela donne à l’équipe une orientation claire et définit les attentes de la direction et des clients concernant chaque livrable du projet.

#3 – Responsabilité de l’équipe

Le/la manager de projet tient les membres de l’équipe responsables d’honorer leurs engagements.

Cela aide le projet à rester sur la bonne voie et à éviter les dérapages de calendrier et les dépendances manquées.

#4 – Champ d’application clairement défini

Le/la manager de projet travaille avec les clients et l’équipe pour s’assurer que la portée est bien définie dès le départ.

Cela permet à l’équipe d’écrire des exigences claires, et tout le monde a la même compréhension de ce qu’il faut livrer à la fin du projet.

#5 – Gestion du budget et des coûts

Le/la manager de projet recueille des informations sur le coût du projet et crée le budget du projet lors de la planification du projet.

À l’avenir, il/elle gère également les dépenses du projet tout au long du projet et s’assure que le projet respecte le budget sans surprise.

Ressource : Comment créer un budget de projet informatique [modèle inclus]

#6 – Gestion des délais / Respect des engagements et des délais envers les clients

Le/la manager de projet aide l’équipe à rester sur la bonne voie. Il/Elle travaille avec l’équipe pour établir le calendrier du projet et identifier les jalons et les livrables.

Il/Elle identifie et travaille avec les parties prenantes pour remédier ou éliminer les obstacles et assurer une coordination et des progrès continus.

Le/la manager de projet gère également les interdépendances entre les équipes afin que toutes les pièces du projet soient réunies pour répondre au besoin.

Il/Elle garde également l’équipe concentrée sur le respect des dates et des jalons clés.

Ce point de contact unique pour l’équipe élimine la confusion quant à savoir qui coordonne et dirige l’effort. Cela garantit une exécution plus réussie du projet.

#7 – Gestion de la portée du projet

Bien qu’il soit important d’avoir une portée de projet clairement définie au début du projet, il est tout aussi important de gérer les dérives de la portée au fur et à mesure que le projet progresse.

Les clients demandent souvent des changements de contenu.

Le/la manager de projet peut aider à montrer comment cela affecte le projet. Si des changements de portée sont effectivement nécessaires, le/la manager de projet peut gérer les impacts sur le planning et le budget du projet.

#8 – Management des risques

Le management des risques comprend l’identification des risques dès le début du processus et leur traitement avant qu’ils ne causent des problèmes. Cela implique également de gérer le changement tout au long du projet en suivant les changements et en les communiquant efficacement.

Le/la manager de projet identifie les risques potentiels au début du projet. Il/Elle travaille avec l’équipe pour manager activement les risques tout au long de la vie du projet.

Grâce à cela, le projet peut aller de l’avant même s’il y a des menaces sur le plan de projet.

Ressource : Comment créer une matrice de management des risques projet (avec modèle)

#9 – Qualité de la solution

Le/la manager de projet travaille avec l’équipe pour intégrer la qualité dans le projet dès le début.

Il/Elle projet s’assure que l’équipe suit les processus appropriés, tels que la collecte des exigences et les tests, le cas échéant. L’équipe peut avoir besoin de suivre les directives de conformité ou les considérations contractuelles. Tout au long de la vie du projet, le/la manager de projet coordonne de multiples activités pour aborder la qualité.

#10 – Tenue des dossiers et responsabilités administratives

Il n’est pas nécessaire d’avoir un/une manager de projet pour créer de la documentation et planifier des réunions.

Mais le/la manager de projet comprend le projet à un niveau supérieur et sait quand planifier une réunion et qui amener à la table. Il/Elle anticipe la nécessité de discussions importantes sur le projet et dirige ces activités pour que le projet continue d’aller de l’avant et sur la bonne voie. Il/Elle s’assure que les documents nécessaires sont créés et stockés à des fins de conformité et d’historique.

#11 – Visibilité de la santé du projet

Le/la manager de projet donne de la visibilité sur l’avancement et l’état du projet. Parce qu’il/elle est responsable de la réussite du projet, le/la manager de projet rassemble toutes les informations et donne de la visibilité sur la santé du projet.

Le logiciel de gestion de projet permet aux équipes de fournir des informations et de fournir une santé de projet en temps réel. Les membres de l’équipe et les parties prenantes peuvent obtenir des mises à jour plus rapides sur l’état et les métriques. L’équipe peut procéder comme prévu ou s’ajuster au besoin en fonction de ces informations. Cela permet à l’organisation d’économiser du temps et de l’argent à long terme.

#12 – Les organisations peuvent entreprendre des projets plus complexes

Les projets plus complexes ont un besoin plus élevé de direction globale et de management d’ensemble.

Avoir un/une manager de projet permet l’exécution réussie de projets plus complexes avec de nombreuses interdépendances et davantage de risques.

#13 – Consolidation d’équipe

Étant donné que le succès du projet dépend de nombreux différents membres d’équipe, vous devez réunir cette équipe de projet pour vous concentrer sur l’objectif commun.

S’il y a des conflits, des agendas personnels ou des désirs contradictoires, le projet pourrait stagner ou se désagréger.

Un/une bon/bonne manager de projet sait comment rassembler l’équipe pour travailler vers un succès commun.

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

#14 – Communications

Le/la manager de projet communique avec les parties prenantes et l’équipe tout au long du projet. Il/Elle utilise des méthodes de communication efficaces comme le courrier électronique, les appels téléphoniques et les réunions en face à face pour faire passer le message.

Pour les projets complexes, le plan de communication définit qui gère différents types de communications tout au long du projet.

Le/la manager de projet sert de point de contact principal pour les communications de projet avec divers publics.

  • Communication avec les membres de l’équipe – Le/la manager de projet coordonne les discussions sur les enjeux et les besoins de l’équipe et facilite la communication entre les départements. Il existe de nombreux sujets à aborder tout au long de la vie d’un projet, tels que la conformité, les risques et les interdépendances.
  • Communication avec les parties prenantes – tenir les parties prenantes informées de diverses manières, telles que des mises à jour de statut, des vues et des informations de haut niveau, ou plus de détails sur le projet si nécessaire.  Les managers de projet communiquent avec les parties prenantes internes et externes.
  • Communication client – plutôt que l’équipe de développement parle directement avec le client, Le/la manager de projet gère ces communications. Il/Elle répond aux questions et traduit les exigences et les détails techniques en termes que les utilisateurs non techniques peuvent comprendre. Il/Elle gère également les attentes des clients tout au long du projet et coordonne les activités de management du changement.

#15 – Management du changement

Le/la manager de projet travaille avec l’organisation pour s’assurer que non seulement le travail de projet est effectué, mais que les clients sont prêts à l’adopter.

Le/la manager de projet de projet planifie les changements nécessaires pour une transition en douceur vers la nouvelle solution.

Voici comment il/elle procède :

  • Communications sur l’échéancier et la date de livraison.
  • Formation aux nouvelles solutions ou nouveaux processus.
  • Mise en place un soutien continu.

Cela offre une meilleure expérience client du début à la fin.

Le management de projet offre des bénéfices aux organisations qui ont besoin de livrer des solutions.

Cette valeur s’applique du niveau de l’équipe jusqu’aux parties prenantes et aux dirigeants. Les managers de projet utilisent un logiciel de gestion de projet, d’autres outils de gestion de projet et des compétences en management de projet pour garantir la réussite de la livraison du projet.

Et vous, en tant que manager de projet, dirigez et menez et vous assurez que l’organisation tire le plein avantage de tout ce que vous faites. Cela vous rend extrêmement précieux pour toute organisation avec laquelle vous travaillez. Du niveau de l’équipe jusqu’au comité exécutif où ils examinent les résultats et les impacts business. Soyez fier de vous. Vous êtes manager de projet.

15 avantages que vous apporte le management de projet (7 à 9)

Le par mopertodans experience sharingLaisser un commentaire

Le management de projet offre de considérables avantages et bénéfices aux organisations qui ont besoin de livrer des solutions.

Benefits of Project Management par Leigh Espy

#7 – Gestion de la portée du projet

Bien qu’il soit important d’avoir une portée de projet clairement définie au début du projet, il est tout aussi important de gérer les dérives de la portée au fur et à mesure que le projet progresse.

Les clients demandent souvent des changements de contenu.

Le/la manager de projet peut aider à montrer comment cela affecte le projet. Si des changements de portée sont effectivement nécessaires, le/la manager de projet peut gérer les impacts sur le planning et le budget du projet.

#8 – Management des risques

Le management des risques comprend l’identification des risques dès le début du processus et leur traitement avant qu’ils ne causent des problèmes. Cela implique également de gérer le changement tout au long du projet en suivant les changements et en les communiquant efficacement.

Le/la manager de projet identifie les risques potentiels au début du projet. Il/Elle travaille avec l’équipe pour manager activement les risques tout au long de la vie du projet.

Grâce à cela, le projet peut aller de l’avant même s’il y a des menaces sur le plan de projet.

Ressource : Comment créer une matrice de management des risques projet (avec modèle)

#9 – Qualité de la solution

Le/la manager de projet travaille avec l’équipe pour intégrer la qualité dans le projet dès le début.

Il/Elle projet s’assure que l’équipe suit les processus appropriés, tels que la collecte des exigences et les tests, le cas échéant. L’équipe peut avoir besoin de suivre les directives de conformité ou les considérations contractuelles. Tout au long de la vie du projet, le/la manager de projet coordonne de multiples activités pour aborder la qualité

 

15 avantages que vous apporte le management de projet (4 à 6)

Le par mopertodans experience sharingLaisser un commentaire

Le management de projet offre de considérables avantages et bénéfices aux organisations qui ont besoin de livrer des solutions.

Benefits of Project Management par Leigh Espy

#4 – Champ d’application clairement défini

Le/la manager de projet travaille avec les clients et l’équipe pour s’assurer que la portée est bien définie dès le départ.

Cela permet à l’équipe d’écrire des exigences claires, et tout le monde a la même compréhension de ce qu’il faut livrer à la fin du projet.

#5 – Gestion du budget et des coûts

Le/la manager de projet recueille des informations sur le coût du projet et crée le budget du projet lors de la planification du projet.

À l’avenir, il/elle gère également les dépenses du projet tout au long du projet et s’assure que le projet respecte le budget sans surprise.

Ressource : Comment créer un budget de projet informatique [modèle inclus]

#6 – Gestion des délais / Respect des engagements et des délais envers les clients

Le/la manager de projet aide l’équipe à rester sur la bonne voie. Il/Elle travaille avec l’équipe pour établir le calendrier du projet et identifier les jalons et les livrables.

Il/Elle identifie et travaille avec les parties prenantes pour remédier ou éliminer les obstacles et assurer une coordination et des progrès continus.

Le/la manager de projet gère également les interdépendances entre les équipes afin que toutes les pièces du projet soient réunies pour répondre au besoin.

Il/Elle garde également l’équipe concentrée sur le respect des dates et des jalons clés.

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

Ce point de contact unique pour l’équipe élimine la confusion quant à savoir qui coordonne et dirige l’effort. Cela garantit une exécution plus réussie du projet

 

Avec Scrum, quand un sprint est-il terminé ?

Le par mopertodans agileLaisser un commentaire

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé.

In Scrum, when is a sprint over?

https://www.extremeuncertainty.com/in-scrum-when-is-a-sprint-over/ par Leon Tranter

Le Sprint est l’un des concepts de base de Scrum. En fait, c’est l’un des cinq événements de Scrum (avec Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective).

Beaucoup de gens bloquent sur essayer de comprendre quand un sprint est vraiment terminé. Pour le comprendre, vous devez comprendre le but d’un sprint et pourquoi il est timeboxé (réalisé sur une période de temps limitée).

CertYou est partenaire de DantotsuPM, allez voir les certifications Agile

Qu’est-ce qu’un sprint ?

Un sprint est l’unité de temps fondamentale dans Scrum. Il s’agit d’une timebox (une durée spécifique et forcée) pendant laquelle une équipe Scrum tente de créer un ou plusieurs incréments de produit. Tous les événements Scrum (Daily Scrum, Sprint Planning, Sprint Review et Sprint Retrospective) se déroulent au sein d’un sprint.

Il n’y a pas d’activité en dehors du sprint.

Une fois qu’un sprint se termine, le sprint suivant commence immédiatement et le cycle de sprint recommence. Il n’y a pas de sprints spéciaux comme « sprint zéro », ou « sprint de consolidation » ou « sprint de release ». A chaque sprint, l’équipe est destinée à déplacer certains éléments du backlog produit vers Done (Terminé) et à livrer un incrément de produit.

Et surtout, un sprint est strictement limité dans le temps, généralement deux semaines, bien qu’il puisse durer jusqu’à un mois.

Pourquoi est-il timeboxé ?

La limite de temps de sprint est très importante. Les équipes doivent accepter la timebox et la respecter, c’est-à-dire mettre fin au sprint et commencer un nouveau sprint une fois la timebox terminée.

Il est parfois tentant pour une équipe de laisser un sprint « traîner » un ou deux jours de plus, pour essayer de finaliser certains éléments, mais cela va à l’encontre de l’essentiel !

Si une équipe commence à faire cela, elle peut continuer à le faire, et le faire de plus en plus. Cela remonte à l’époque des méthodes prédictives dites en cascades, où les livraisons sont repoussées toujours plus tard car les équipes veulent mettre tout le contenu de leur périmètre fonctionnel dans une unique livraison ou release. Avant que vous ne vous en rendiez compte, vous pouvez revenir à une release tous les 6 mois !

La timebox stricte garantit qu’il existe un modèle régulier simple, une cadence, où une équipe s’arrête et inspecte son dernier livrable (dans la revue de sprint) et l’équipe elle-même (dans la rétrospective de sprint).

Quand un sprint est-il terminé ?

La réponse courte et simple est qu’un sprint est terminé lorsque la timebox de sprint se termine ! (Quelle que soit la cadence choisie par l’équipe pour les sprints, c’est-à-dire deux semaines, un mois, une semaine, etc.).

Une équipe peut choisir de changer la durée de ses sprints (c’est-à-dire que l’équipe peut choisir de passer de sprints de deux semaines à des sprints d’une semaine ou vice versa), mais ce n’est pas un changement ponctuel. Cette nouvelle timebox devient la timebox standard pour tous les sprints à partir de là (jusqu’à la prochaine fois que l’équipe voudra changer la timebox).

Un sprint n’est pas terminé lorsqu’un incrément de produit est créé ou livré. L’équipe continue simplement à travailler sur d’autres éléments de l’arriéré de produit ou product backlog. Elle peut même produire un autre incrément de produit dans ce sprinte (Il n’y a rien dans Scrum qui dit que vous ne puissiez livrer qu’un seul incrément de produit par sprint !).

Un sprint n’est pas non plus terminé lorsque l’objectif de sprint a été atteint. Dans la situation heureuse où il reste encore un peu de temps dans le sprint, l’équipe peut choisir d’effectuer le travail qu’elle veut dans le temps restant. Il peut s’agir de travailler sur d’autres éléments du product backlog, rembourser une dette technique, examiner certains éléments d’amélioration continue, etc.

L’important est que la timebox régulière soit respectée.

De quelles autres façons un sprint peut-il se terminer ?

Il n’y a que deux autres façons dont un sprint peut se terminer.

La première est si le Product Owner décide d’annuler le sprint en cours. C’est un cas extrême qui ne devrait arriver que très rarement. La seule raison donnée pour cela dans le Guide Scrum est que l’objectif de sprint est devenu obsolète. Cela peut se produire pour diverses raisons, mais elles ne devraient pas arriver souvent. Il est presque toujours plus bénéfique pour l’équipe de continuer et de terminer le travail qu’elle a prévu pour ce sprint.

Il n’y a pas d’autres moyens mentionnés dans le Guide Scrum. Le seul auquel je puisse penser est un exemple encore plus extrême et, espérons-le, rare. C’est si le produit ou l’équipe elle-même cesse d’exister. Si une équipe est au milieu d’un sprint et que, pour une raison quelconque, l’organisation décide d’arrêter tout travail sur le produit ou d’arrêter de financer l’équipe, alors évidemment ce sprint se termine.

L’organisation peut vouloir financer l’équipe pour le reste du sprint, mais si le produit lui-même est obsolète ou n’est plus financé, elle peut vouloir économiser de l’argent en ne terminant pas le travail en cours dans le sprint.

Les exigences SMART sont Agiles

Le par mopertodans agile, outils et méthodesLaisser un commentaire

Des approches SMART sont utilisées pour évaluer les exigences dans les projets en cascade, prédictifs. Elles s’appliquent aussi aux projets agiles.

SMART Requirements are Agile

http://www.bonniebiafore.com/smart-requirements-are-agile/ par Bonnie Biafore

Spécifique

Dans Agile, des exigences spécifiques documentées n’existent pas au départ. Spécifique se rapporte au livrable final. En Agile, les exigences sont capturées pendant le développement, pas documentées à l’avance. Cependant, le résultat final va typiquement au-delà du détail et de la spécificité d’exigences traditionnelles. Quand de grandes exigences ne sont pas spécifiques, elles sont typiquement décomposées en plusieurs histoires utilisateur en Agile, dont chacune fournit une fonctionnalité spécifique et peut être plus facilement produite.

Mesurable.

La construction et l’évaluation de chaque fonctionnalité se concentrent sur la mesure de l’efficacité. Un des bénéfices les plus significatifs d’Agile est que cette exécution et ces mesures de pertinence sont construites et mesurées durant le processus de développement. Avec une mentalité de prototypage, des fonctionnalités Agiles peuvent être évaluées par des utilisateurs avant leur mise en œuvre. Quand cela ne peut pas être fait directement, par exemple, quand un processus commercial totalement nouveau est créé, l’association développeur-utilisateur utilisée pour construire les fonctionnalités Agile réduit le risque de livrables ne réussissant pas à atteindre des objectifs business mesurables.

Atteignable

Le classement par taille de fonctionnalité et la priorisation assurent que la faisabilité est régulièrement évaluée. Les fonctionnalités sont examinées pour leur intégrité et capacité à être produites en un sprint. De plus grandes fonctionnalités sont décomposées en morceaux qui sont plus facilement créés, augmentant la faisabilité.

Quand les fonctionnalités ne peuvent pas être décomposées en parties gérables, c’est un signe qu’elles ne sont pas réalisables.

Les développeurs et les utilisateurs peuvent examiner ces fonctionnalités en temps réel pour déterminer à quel point elles sont critiques et explorer d’autres façons d’adresser le besoin business.

Réaliste

Une approche pratique de comment planifier et implémenter le changement

En Agile, les fonctionnalités sont développées et acceptées itérativement et en temps réel, par rapport à des semaines ou des mois après que les exigences soient documentées dans l’approche traditionnelle prédictive.

Agile se prête aux résultats réalistes et peut intégrer les derniers changements aux besoins business.

La nature d’Agile signifie que l’équipe entre plus profondément dans les fonctionnalités et leurs capacités, permettant aux utilisateurs de rendre les livrables plus faciles à utiliser. Les fonctionnalités présentent une plus grande intégrité et supportent de meilleurs processus business.

Temporel – contraint par le Temps

L’approche par sprints est idéale pour s’assurer que les contraintes de temps soient placées sur la création de fonctionnalités. De plus, il y a la valeur supplémentaire de pouvoir facilement changer les durées quand des priorités business changent. La re-priorisation et la planification de fonctionnalités avant chaque sprint fournissent un focus soutenu sur les périodes de développement. Bien que cette approche de gestion des délais ne soit pas parfaite, les fonctionnalités qui exigent plus de temps que prévu à développer sont réévaluées et reportées aux sprints suivants comme décidé au sein de l’équipe Agile.

QRP est partenaire de DantotsuPM, visitez leur site et leur blog

“Trick or Treat” : Leçons de management de projet de Halloween !

Le par mopertodans experience sharingLaisser un commentaire

Pour vous mettre dans l’ambiance du 31 octobre, voici quelques leçons de management de projet tirées de Halloween.

https://kbondale.wordpress.com/2021/10/10/project-management-lessons-from-trick-or-treating/ par Kiron Bondale

[…]

Moins, c’est plus

Livre sur Amazon

Il peut être tentant d’aller trop loin avec les décorations au sujet des excès d’éclairage mais résistez. Rappelez-vous que les meilleures peurs viennent de ce qui n’est pas vu mais qui est implicite.

Lorsque vos intervenants essaient d’ajouter du contenu dans le périmètre d’un projet, aidez-les à se concentrer sur le minimum requis pour atteindre les résultats escomptés. Cela aidera à contenir les coûts, à réduire les risques et à produire de la valeur plus rapidement.

Un peu de management des risques apporte beaucoup

C’est peut-être une légende urbaine, mais voulez-vous vraiment mordre dans un morceau de sucrerie et trouver une épingle ou un autre objet étranger néfaste à l’intérieur ? Attendre que nous rentrions à la maison et que nos parents vérifient notre butin est une pratique simple et sûre.

Portez n’importe le costume que vous choisissez, assurez-vous qu’il y a des bandes réfléchissantes de sorte que les conducteurs vous voient quand vous traversez la rue en courant.

Pour être efficace, le management des risques doit être perçu comme une valeur ajoutée et pragmatique. Si vous devez faire des très difficiles efforts pour convaincre vos parties prenantes de répondre aux risques, il est probable que vous faites mal quelque chose.

Planifiez, mais soyez prêt à changer vos plans

L’expérience préalable d’un quartier aide les enfants à planifier leur tournée et itinéraires afin de recevoir le maximum de sucreries pour un effort minimum. Mais il est également possible qu’au cours d’une année, la dynamique de l’offre des récompenses puisse changer à mesure que les gens déménagent. Par conséquent, c’est une bonne idée de rester en contact avec vos copains afin que, s’ils sont grassement récompensés dans leurs rues alors que le nôtre est nulle, vous puissiez aller vers chez eux.

Un plan n’est aussi bon que les hypothèses qui le sous-tendent. Lorsque ces hypothèses sont invalidées, nous devons oublier notre ego à propos du plan lui-même et le modifier pour mieux refléter la réalité.

Livre sur Amazon

Suivez ces leçons simples si vous souhaitez que la citrouille du management de projet vous récompenser lors de cet Halloween !

Si vous avez aimé cet article, pourquoi ne pas lire le livre de Kiron Bonale : « Easy in Theory, Difficult in Practice » qui contient 100 autres leçons sur le leadership de projet ?

Gérer la portée (contenu, périmètre) du projet en évaluant la propriété.

Le par mopertodans best practicesLaisser un commentaire

Avez-vous un propriétaire approprié pour ce nouvel élément à inclure dans le périmètre de votre projet ?

Manage Scope by Assessing Ownership

http://www.bonniebiafore.com/manage-scope-by-assessing-ownership/ de  Bonnie Biafore

Lorsque les idées de projet circulent librement, manager le contenu peut être difficile. Un moyen sûr de gérer la portée du projet consiste à évaluer la propriété. À moins que le propriétaire identifié ne soit approprié, cet élément ne doit pas faire partie de votre projet.

QRP est partenaire de DantotsuPM

Un(e) propriétaire est approprié(e) lorsque :

Il/Elle peut fournir du financement.

Les propriétaires appropriés financeront l’élaboration de leur nouvel élément de portée. De plus, ils peuvent augmenter le financement (dans le cadre des paramètres du cas d’affaire) si le coût de la prestation de la portée augmente.  Si les propriétaires identifiés doivent aller ailleurs pour obtenir ou débloquer des fonds, ils ne sont pas des propriétaires adéquats.

Il/Elle peut fournir des ressources.

Les propriétaires appropriés fournissent des ressources compétentes pour détailler les exigences, les vérifier et mettre en œuvre les éléments additionnels. Fournir des ressources novices ou de niveau moindre pourrait indiquer un manque d’appropriation du besoin. Les retards dans l’obtention des ressources peuvent indiquer que d’autres éléments de portée ont une priorité plus élevée, auquel cas vous devez évaluer si l’élément de portée doit vraiment être dans le périmètre du projet.

Il/Elle peut prendre des décisions.

Les propriétaires d’éléments additionnels peuvent prendre des décisions concernant la façon dont cette extension de périmètre sera générée et implémentée. Alors que d’autres peuvent participer à la prise de décision, le propriétaire approprié est l’arbitre final.  Dans les cas où les décisions relatives à la portée touchent d’autres personnes, le propriétaire approprié a les moyens de consulter et d’influencer les autres au sujet de l’élément de portée (pour résoudre les conflits potentiels avec les autres intervenants).

Il/Elle défend les besoins de l’entreprise.

Les contraintes de projet peuvent nécessiter la hiérarchisation de la portée. Un propriétaire approprié peut articuler et défendre le besoin opérationnel pour ses éléments dans le périmètre du projet. Au fur et à mesure que le projet progresse, ils se rendent disponibles pour discuter des changements requis et évaluer les répercussions de ces changements sur leur entreprise.

Quelques conseils avisés pour avoir un objectif de projet que les gens peuvent comprendre.

Le par mopertodans best practicesLaisser un commentaire

L’une des clés du succès est de s’assurer que tout le monde comprend ce que votre projet est censé accomplir.

A project goal that people can understand

http://www.bonniebiafore.com/a-project-goal-that-people-can-understand/ de  Bonnie Biafore

L’une des clés du succès est de s’assurer que tout le monde comprend ce que votre projet est censé accomplir. Voici des conseils pour mettre en place un objectif de projet qui maintiendra votre projet sur la bonne voie vers le succès.

Identifiez un objectif ou un problème métier spécifique à résoudre.

Les projets réussis résolvent un problème existant important ou produisent de nouvelles capacités pour l’entreprise et/ou ses clients. L’objectif du projet devrait décrire succinctement la capacité ou l’enjeu, ainsi que les résultats que le projet produira. Par exemple : « Le projet comblera les lacunes dans le suivi des expéditions vers nos régions éloignées en créant une extension de notre application logistique existante. »

Vérifiez l’objectif au-delà de votre sponsor et de votre client principal.

En tant qu’intervenants clés, le sponsor du projet et le client principal doivent appuyer l’énoncé des objectifs du projet. Pour assurer un objectif de projet précis et significatif, effectuez un inventaire des parties prenantes et vérifiez l’objectif du projet auprès d’autres leaders influents. De cette façon, vous évitez les questions sur l’intention ou la portée du projet qui pourraient retarder son lancement.

De plus petits objectifs fonctionnent mieux.

Les grands objectifs sont parfois difficiles à pleinement appréhender.

Les objectifs du projet peuvent être assez vastes, ce qui est non seulement bien, mais aussi souvent nécessaire. Cependant, des objectifs plus petits atteints grâce à une série de projets ciblés sont moins risqués que d’essayer d’exécuter un énorme projet. Les approches agiles embrassent ce concept. Divisez votre objectif en plus petits morceaux car cela signifie atteindre des résultats plus tôt. En outre, des objectifs plus petits pourraient réduire la nécessité d’activités de management du changement organisationnel. Vous pouvez atteindre des objectifs importants en livrant par étapes progressives.

Ne diluez pas l’objectif.

Chaque tâche doit être un pas vers l’objectif final.

Assurez-vous que chaque tâche de projet vous aide à atteindre votre objectif. Surtout dans les projets les plus longs, d’autres objectifs trouvent le moyen de se faufiler dans votre projet. Assurez-vous que vous et les membres de votre équipe vous concentrez uniquement sur le travail nécessaire pour terminer votre projet tel que défini. Appliquez un processus de management du changement rigoureux pour éviter la dérive de portée et vous serez sur la bonne voie pour obtenir des résultats positifs !

Pour en savoir plus sur le management de projet, consultez le cours de Bonnie Biafore : Project Management Foundations.

CSP est partenaire de DantotsuPM