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

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 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é ?

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

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 !

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

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.

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

Lundi de Pâques : Prenez du recul sur votre projet. Avez-vous un problème de chocolat ou un problème d’oxygène ?

Dans nos projets, posons-nous une question et posons-la surtout à nos parties prenantes et commanditaires : Qu’est-ce qui est réellement vital pour la réussite du projet ?

Cette exigence est-elle un carré de plus de chocolat ou bien l’oxygène sans lequel vous ne pourrez vivre ?


A propos des besoins vitaux et des autres besoins et de comment bien faire la différence par Seth Godin.

Do you have a chocolate problem or an oxygen problem?

Soyez à court le chocolat et c’est la honte. Soyez à court d’oxygène et vous êtes foutus.

Parfois, nous exagérons notre dépendance au chocolat. Il est meilleur à petites doses : Trop et il perd de sa magie. Et parfois nous confondons la chose que nous voulons avec la chose dont nous avons besoin

Si votre journée ou votre projet ou votre organisation se concentrent trop sur trouver le prochain carré de chocolat, vous pourriez oublier de vous concentrer sur l’oxygène dont vous avez en réalité besoin pour vivre.

Bien plus qu’un outil de gestion de projet
Découvrir l’ERP de gestion de projet

Et si vous donniez aux 2% de vos prospects les 100% de ce qu’ils souhaitent plutôt qu’à 100% les 2% de leurs besoins ?

Ce sont les clients pleinement satisfaits, delighted comme le disent les anglophones, qui font votre succès et votre réputation.

Apprenons à choisir nos clients comme nos batailles et nos succès seront bien plus retentissants.

Pensons également à étendre cette maxime au niveau du portefeuille de projets pour apprendre à choisir nos projets : « Vaut-il mieux lancer 2 projets qui répondront à 100% des attentes de quelques clients précieux que ces 10 autres  qui ne satisferont que partiellement un plus grand nombre de clients ? »

Hexagon est partenaire de DantotsuPM

s’autoriser soi-même : maxime à appliquer dans vos projets dès la rentrée (et même avant pour les projets personnels) !

Nous nous interdisons souvent trop de choses dans nos projets.

Nous avons une tendance naturelle à nous auto-censurer. Hors, pour dépasser les attentes de nos clients et de nos équipes projets, il faut souvent aller juste un peu plus loin que ce qui est demandé ou attendu: Livrables, qualité, délais, ambiance de travail…

C’est en étonnant que l’on peut faire une réelle différence dans le business et dans les relations avec ses équipes, sponsor et clients.