Tag Archives: planning

29 March – Webinar #PMI® – Scheduling Conference 2017

4 Fév

Tackle Challenges and innovate in your scheduling capabilities to Stay Ahead of Change

details and registration

details and registration

Scheduling for Agile, Hybrid Projects, PMOs and Beyond

New technologies, hybrid projects, the launch of a PMO—when the environment is constantly changing, how do you craft a schedule (or multiple schedules) for project success?

Discover timely answers at the PMI Scheduling Conference 2017, exclusively for PMI members.

Genius Project est partenaire de DantotsuPM

Genius Project est partenaire de DantotsuPM

Whether you are specializing in scheduling or ramping up your skills for larger projects, you will not want to miss:

  • Tips on working with Agile practices and dealing with hybrid (Agile, Waterfall) project challenges
  • Guidance on planning activities across geographic regions and technologies
  • Insights into setting schedules for PMO success

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

Enregistrer

Enregistrer

5 façons de rester proactif pendant des retards de projet

22 Déc

vous pouvez réduire les effets négatifs des retards de projet par cinq actions clés

5 Ways to Stay Proactive During Project Delays

http://www.ims-web.com/blog/5-ways-to-stay-proactive-during-project-delays par Jeff Collins

Des retards de projet sont une partie inhérente de n’importe quel projet.

waitingDes retards de projet surviennent en conséquence de la piètre planification, de communication inadéquate, de réduction des ressources allouées et de changements dans le contenu du projet. En outre, les retards de projet appauvrissent le moral des collaborateurs et réduisent la vitalité de votre équipe de management de projet.

Heureusement, vous pouvez réduire les effets négatifs des retards de projet par cinq actions clés. Lisez ce qui suit pour voir comment votre équipe de management de projet peut maintenir un environnement positif et rester productive quand des retards de projet arrivent.

1. Tenez des réunions avec les membres de l’équipe et ressources qualifiées

Office workers in meeting --- Image by © Royalty-Free/Corbis

Image by © Royalty-Free/Corbis

Les membres de l’équipe et des ressources qualifiées peuvent ignorer des retards actuels du projet. Donc, entretenez un bon niveau de communication avec les membres de l’équipe et personnes qualifiées est critique pour garantir que des retards dans le projet n’aboutissent pas à l’échec du projet. Tenez des réunions quotidiennes avec tous les contributeurs et membres de l’équipe pendant la durée de ces retards de projet. Sollicitez des retours d’information et options possibles ou façons de réduire les effets négatifs du retard de leur part. En restant connectés, vous pouvez maintenir une relation positive avec toutes les parties affectées.

NQI est Partenaire de DantotsuPM

NQI est Partenaire de DantotsuPM

2. Réévaluez l’état actuel de votre projet et autres retards potentiels

effet domino dans les dérivesLes retards peuvent être un indicateur de problèmes à venir sur votre projet. Quand les retards surviennent, réévaluez l’état actuel de votre projet. Comment ce retard initial impactera-t-il d’autres tâches et activités ? Est-ce que ce retard est raisonnable, ou est-il simplement un moyen de réduire le coût de votre projet ? Ces questions identifieront pourquoi le retard est là et comment des retards semblables pourraient être minimisés dans l’avenir.

3. Réaffectez les ressources à des activités et tâches non-retardées

Si le retard est localisé sur des tâches et activités spécifiques, vous pouvez pouvoir déplacer des travailleurs et des allocations de ressources vers des tâches non-affectées. Bien que ceci change le planning des activités, il permet à votre personnel de rester productif quand votre projet souffre de retards. En outre, vous devez considérer comment les retards affecteront le périmètre global de votre projet.

Essayez Bubble Plan !

Essayez Bubble Plan !

4. Revisitez vos données capturées pour l’analyse de risque

Parfois, les retards peuvent être le résultat de votre équipe projet et l’incapacité des personnes à réaliser dans des délais peu réalistes. Si les retards semblent arriver sans avis du management exécutif, passez en revue les données et facteurs dans votre analyse de risques. Conduisez une session supplémentaire d’analyse de management des risques pour définir pourquoi et comment les problèmes sont survenus. Si le problème réside avec un membre spécifique de l’équipe, envisagez de fournir une formation supplémentaire pour corriger le problème.

5. Conduisez une inspection de la qualité des livrables achevés et en cours

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Certains retards de projet peuvent saper la capacité de votre équipe à compléter un projet dans un délai donné. Cependant, des retards ne peuvent être évités et votre équipe doit rester productive pendant tout le projet. Demandez aux membres de l’équipe et contributeurs de conduire des inspections de la qualité du travail réalisé et rechercher des erreurs. Bien que cette étape soit normalement la dernière partie d’un projet, vous pouvez réduire l’impact global des retards en conduisant des inspections de qualité en continu.

Quand vous ignorez la possibilité de retards de projet, vous allez plus probablement exposer de faibles qualités de leadership et refuser de vous adapter quand les retards arrivent. En prenant ces cinq actions, votre équipe de management peut rester productive pendant ces périodes de retards de projet.

 Retenez ces quelques idées :

  • La communication est l’action la plus importante pour rester productifs pendant des retards de projet.
  • Revoir les échéances de projet et conduire une nouvelle analyse de risque permet d’identifier des retards potentiels dans l’avenir.
  • Commencer à travailler sur d’autres tâches et activités en avance de phase si des retards affectent des parties spécifiques de votre projet.
  • Conduire des inspections de qualité préliminaires si votre équipe est incapable d’exécuter d’autre travail avant que les retards ne soient écoulés.

Enregistrer

les articles les plus lus sur DantotsuPM en Juillet 2016

19 Déc

Plusieurs documents et des pointeurs vers des formations et du développement personnel en ce mois estival où les lecteurs avaient peut-être plus de temps pour réfléchir à comment développer leurs propres capacités et compétences.

Lean Project Management – Téléchargez ce guide gratuit

Si vous ne connaissez pas encore ce guide centré sur l’association du Lean Project Management et des projets de transformations organisationnelles, il n’est pas trop tard pour le lire !

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Scrum Valuesmises à jour du « Scrum Guide »

5 Valeurs : Courage, Focus, Engagement, Respect et Ouverture.

et si vous leviez la tête de ce diagramme de Gantt et preniez le temps de réfléchir ?

Prenez vous du temps chaque jour juste pour vous poser et réfléchir ?

Essayez Bubble Plan !

Essayez Bubble Plan !

Comment faire remplir les suivis de temps par votre équipe ?

Ces 3 étapes simples feront que votre équipe renseigne les suivis de temps…

rubix problem solutionAmenez-moi des solutions pas des problèmes : leadership versus management

Le leadership est une chose dont beaucoup d’organisations manquent.

les chefs de projets restent très recherchés

Selon le baromètre Expectra 2016, les chefs de projets font partie des 10 métiers cadres les plus difficiles à recruter

Les grands chefs de projet peuvent manager quoi que ce soit!

Les bons chefs de projet ont des compétences qui s’appliquent dans chaque profession liée au management.

Découvrez le MOOC d’introduction aux certifications professionnelles du PMI®

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Durée de Sprint, quelle est la bonne durée ?

16 Déc

Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie mais il y a 2 principes pour en déterminer la valeur optimale pour votre projet.

Sprint Length: What Length is the Right Length?

http://blog.3back.com/scrum-tips/sprint-length-what-length-is-the-right-length/ Par Docteur Dan Rawsthorne

hourglass-time-cloclk-deadline-sablierOn me demande souvent, ‘Combien de temps devrait durer un Sprint pour mon équipe ?’ Et ‘le Sprint doit-il être de durée fixe ?’. Je constate qu’il ne suffit pas de répondre : « N’y réfléchissez-y pas trop longtemps. Si vous utilisez un environnement raisonnable et un langage de développement comme Java ou dot-net, utilisez une durée de Sprint de deux semaines. Cela semble marcher pour la plupart des équipes, mais certains utilisent une semaine ou trois semaines. Voyez simplement ce qui vous convient. »

Comme tant de sujets dans Scrum, la durée de Sprint n’est pas fermement définie.

Deux principes sur la durée

Il y a deux principes pour déterminer la durée d’un Sprint.

  1. Le Sprint ne devrait pas être changé après son démarrage.
  2. Les Sprints devraient être de même durée.
Ne pas se mentir à soi-même ni à l'équipe

Ne pas se mentir à soi-même ni à l’équipe

Je pense que la première règle est claire et directe. Ce serait tricher que de changer la durée du Sprint après qu’il ait commencé. Si l’équipe ferme les yeux sur le changement de la durée de Sprint, elle sera tentée de changer la définition de « Done » pour permettre certains changements de contenu. Ceci est une mauvaise chose: La chose correcte à faire est d’ajouter une autre histoire utilisateur (User story) à l’Arriéré de produit (Product Backlog).

Quant aux Sprints devant tous être de même durée, c’est un peu plus délicat. J’ai déjà dit qu’un Sprint de démarrage pourrait être de seulement une semaine, donc, clairement je ne suis pas totalement inflexible sur le fait que tous les Sprints devraient être de même durée. Puisqu’un Sprint est une boucle de retour d’information, l’équipe doit prendre en compte les parties prenantes. Avoir une durée de Sprint fixe donne aux parties prenantes un rythme constant pour les revues de livrables, ce qui est réconfortant et installe une routine familière. Cependant, avoir des durées de Sprint différentes pour des Sprints spécialisés, comme la prise en compte des périodes de fêtes (ou des vacances), ou une autre raison dont l’équipe et les parties prenantes peuvent convenir, ne me semble pas être une terriblement mauvaise chose.

Est-ce assez long ?

estimate durationUn Sprint doit être assez long pour vraiment achever des histoires (user stories). C’est-à-dire l’équipe doit pouvoir amener ses histoires jusqu’à leur état fini (« done »). C’est une règle dans Scrum qu’un Sprint ne devrait jamais excéder un mois. En général, la longueur de Sprint devrait être approximativement de trois fois le temps nécessaire à analyser et réaliser totalement une histoire de taille moyenne. Ceci semble donner assez de flexibilité dans le système pour permettre à l’équipe de s’auto-organiser pour obtenir un travail fini. Mon expérience est qu’une histoire prend environ 2-3 jours pour une équipe typique qui est bien en place, donc une longueur de Sprint raisonnable est deux semaines. Cependant, les environnements sont différents; certains sont plus faciles (ou plus difficiles) que d’autres. Je m’attends donc à ce que les longueurs de Sprint d’une équipe varient largement en fonction de ces différences d’environnement.

Est-ce assez court ?

La durée de Sprint devrait être suffisamment courte pour que le changement d’avis sur les besoins soit plus lent que la durée du Sprint. C’est-à-dire, si la durée de Sprint est de deux semaines, l’équipe espère que les changements de besoins arrivent plus lentement que toutes les deux semaines. Ce qui veut dire que les parties prenantes peuvent attendre jusqu’à la fin du Sprint pour voir leur ‘nouveau truc’ délivré avant de vouloir le changer.

finiDans l’environnement business actuel, il est typique que la modification de besoins soit trop rapide pour le Sprint. Il y a des bogues à réparer dans d’autres systèmes que l’équipe maintient, il y a des cas d’urgence partout dans l’organisation à fixer et les parties prenantes changent presque constamment d’avis sur ce qui est important. Ce sont autant de raisons pour que l’équipe raccourcisse la durée de Sprint ou celle du cycle de planification.

Des choses se produisent et les équipes développent des méthodes pour manager le fait que des besoins devraient être changés plus d’une fois par Sprint.

Soyez ouverts à re-planification

Parfois la durée de Sprint d’une équipe est juste trop longue pour que survivent les accords pris : la fréquence de changement des besoins est plus rapide que la longueur de Sprint ne peut le supporter. Il est tentant d’essayer de raccourcir les Sprints, mais peut-être n’est-ce pas faisable parce que les parties prenantes ne peuvent pas manager des revues plus fréquentes, ou parce que l’équipe ne peut pas développer plus rapidement.

Essayez Bubble Plan !

Essayez Bubble Plan !

Que fait l’équipe ?

Scrum n’est rien sinon adaptatif. En fait, si l’équipe ne s’adapte pas pour respecter ses propres réalités, ce n’est pas du Scrum. Alors, adaptez-vous… l’équipe pourrait avoir des sessions de planification de Sprint plus fréquentes – peut-être une fois par semaine.

Par exemple, si l’équipe a une durée de Sprint de deux semaines, du lundi au vendredi deux semaines plus tard. Alors, l’équipe pourrait planifier chaque lundi, et non pas seulement un lundi sur deux. Le premier lundi l’équipe remplirait son Sprint à environ 80 % de sa capacité et le deuxième lundi les membres de l’équipe se poseraient la question : « qu’ajoutons-nous maintenant ? »

Je constate que beaucoup d’équipes se sont spontanément déplacées vers ce système, donc c’est un modèle connu qui est très efficace. Il devrait faire partie de la boîte à outils du ScrumMaster.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Comment PRINCE2 peut vous aider à identifier (et prévenir) les échecs de projet

8 Déc

Certaines causes des échecs de projet sont non seulement communes à de nombreux projets mais peuvent aussi être identifiées tôt et même évitées !

8 Common Causes of Project Failure (and how to avoid them!)

http://www.qrpinternational.be/index/news?id=1400

échecPourquoi les projets échouent-ils ?

Les projets peuvent échouer pour de nombreuses de raisons car chaque projet est un voyage en soi et différentes raisons peuvent causer l’échec du projet au final.

Mais la bonne nouvelle est que certaines causes sont non seulement communes à de nombreux projets mais peuvent aussi être identifiées tôt et même évitées !

Considérez la liste ci-dessous, reconnaissez-vous certains de ces échecs de projets ?

Si la réponse est OUI, continuez la lecture : nous avons quelques bonnes astuces pour vous!

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Les 8 causes communes d’échec de projet et les palliatifs !

1) Le manque de lien direct entre le projet et les priorités stratégiques de l’organisation

Être bien aligné sur la stratégie de l'entreprise..

Être bien aligné sur la stratégie de l’entreprise..

Les projets doivent refléter et adresser les objectifs de l’organisation qui les entreprend. Il devrait être possible de démontrer comment chaque projet supporte ces objectifs et prioriser les projets qui fournissent le meilleur retour.

DEUX outils dans votre projet peuvent vous aider à empêcher cette cause d’échec :
  1. Le Cas d’affaires (Business Case) bien conçu : Le cas d’affaire énonce les raisons d’entreprendre le projet et justifie l’investissement. Celles-ci sont clairement documentées et comprises. Très important : le cas d’affaires est passé en revue et mis à jour souvent dans le projet et lors de de tout changement de circonstances.
  2. Le Comité de Projet très impliqué: Le Comité de Projet est un groupe de parties prenantes seniors qui incluent les décideurs clés pour le projet. Ce groupe représente les intérêts de l’organisation. Son rôle collectif est de s’assurer que le projet apporte de la valeur et contribue aux objectifs stratégiques de l’organisation.
SMPP est Partenaire d DantotsuPM

SMPP est Partenaire d DantotsuPM

2) Manque de leadership de la direction générale

leadershipIci aussi, la bonne participation au Comité de Projet essentielle : le comité peut être impliqué dans un processus appelé « Direction de projet » et ceci garantira que les décisions majeures exigé tout au long de la vie du projet sont prises par le personnel le plus senior. La magnitude, la complexité et l’importance du projet détermineront qui participera au Comité de Projet : bien sûr, des membres du Comité de Projet doivent être nommés en fonction de leur autorité à prendre des décisions.

3) Manque d’engagement efficace avec parties prenantes

stakeholderLa participation des parties prenantes clés est critique dans leur engagement dans le projet et prise de responsabilité des livrables associés. Plus les parties prenantes sont passionnées par le projet plus probablement elles sont à impliquées dans l’élimination des obstacles et plus sensibles elles seront à traiter les problèmes dès qu’ils surgissent. Un outil que vous pouvez utiliser pour éviter ce risque est le Plan de Communications. Il s’assure que les parties prenantes sont identifiées pendant la première étape et bien managées ensuite. Ce plan détaille les besoins en informations des parties prenantes et décrit comment l’équipe projet les satisfera.

4) Manque de compétences et d’une approche éprouvée de management de projet

prince2Les méthodes de management de projet sont les résultats de toutes les leçons fournies par divers groupes de Chefs de projet, managers, clients et utilisateurs de ces méthodologies. Ces leçons forment la base d’une approche pragmatique et cohérente du management de projet qui guidera l’équipe projet dans l’application de bonnes pratiques. La méthode fournit des conseils sur les actions requises et les informations nécessaires pour prendre des décisions réfléchies. Il est important que les chefs de projet et les personnes clés impliqués dans des projets soient bien formés et préparés. Ceci donne de l’autonomie à l’équipe et davantage de structure au projet.

5) Trop peu d’attention accordée au découpage du travail et à la mise en œuvre par étapes raisonnables

Le découpage de la charge de travail en étapes réduit l’exposition aux risques et permet la planification précise et le contrôle des progrès. La décomposition du projet en des composants plus faciles à manager rend le défi moins intimidant et fournit une meilleure clarté du périmètre du projet.

Essayez Bubble Plan !

Essayez Bubble Plan !

Un exemple : le principe PRINCE2focus sur les produits‘ et l’utilisation de la technique de planification basée sur les livrables contribue à la définition d’étapes de projet gérables. La décomposition du contenu du projet en produits et la délégation de chaque produit aux responsables d’équipe garantit qu’il y a une attention continuelle sur l’établissement d’étapes raisonnables pour mener vers l’achèvement du projet.

6) Évaluation des propositions pilotées par le prix initial plutôt que le rapport qualité-prix à long terme

Bien que le coût pour livrer un projet est une considération importante, cela ne devrait pas être la seule impliquée dans la détermination de la viabilité d’un projet. Le cas d’affaires justifie le lancement du projet et sa poursuite, il soutient le principe de ‘ justification continue du business’. Le cas d’affaires identifie des bénéfices mesurables et établit la vision à plus long terme de la valeur du projet.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

7) Le manque de compréhension et de contact avec le fournisseur au plus haut niveau de l’organisation

Two wooden mannequins pushing puzzle pieces togetherIl y a, dans chaque projet, un grand besoin d’engager les parties prenantes et de s’assurer que leurs besoins soient respectés et leur expérience et expertise utilisées à l’avantage du projet. Qui peut vous aider à réaliser ceci ? Le rôle est celui du fournisseur principal, il représente les équipes des fournisseurs/vendeurs. Ce rôle fait partie du Comité de Projet, contribuant à toutes les décisions clés.

8) Manque d’intégration efficace de l’équipe projet

Il arrive souvent de constater un manque d’intégration dans l’équipe projet entre clients, l’équipe fournisseurs et la chaine de valeur. Il est crucial de construire et créer un environnement de client-fournisseur qui réconcilie leurs intérêts dans le groupe de prise de décision du projet et facilite l’intégration des divers intérêts.

(Identifié dans une recherche du Bureau Gouvernemental Britannique du Commerce)

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Enregistrer

6 Décembre – Strasbourg (#PMI®) – Mind Mapping : un outil pour simplifier la planification de vos projets et la création des WBS

4 Déc

Pôle Strasbourg, Mardi 6 décembre 2016 à 18h15

Cliquez ici pour une démonstration en ligne !

Cliquez ici pour une démonstration en ligne !

Nous avons tous expérimenté différents moyens de récolter les besoins de nos projets pour pouvoir ensuite les planifier: tableaux blancs, post-it, tableaux informatiques, etc.

Le PMI Strasbourg vous propose de (re)découvrir le Mind Mapping : une manière efficace de recueillir et d’organiser les besoins pour ensuite construire le WBS (Work Breakdown Structure), le diagramme de Gantt, la documentation projet…

La conférence sera animée par Marc Cantain, directeur des ventes chez Matchware, éditeur du logiciel MindView.

Notre conférencier vous présentera la théorie du Mind Mapping et comment ses principes peuvent être appliqués à des chefs de projet. Il partagera également avec vous les meilleures pratiques en matière de Mind Mapping et vous montrera comment son utilisation, couplée à l’outil informatique, simplifie le cycle de vie du projet, fait gagner du temps et améliore la communication d’un plan projet. Les avantages de cette méthode seront démontrés en interaction directe avec les participants au cours de la présentation.

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

Essayez Bubble Plan !

Essayez Bubble Plan !

Enregistrer

Que sont les « Story Points » ou Points d’Histoire en #Agile ?

23 Nov

Les « Story Points » sont  une évaluation de l’effort total qui sera exigé pour entièrement mettre en œuvre un article de l’arriéré de produit.

http://www.mountaingoatsoftware.com/blog/what-are-story-points par Mike Cohn

mesurer et comparerLes «Story Points» sont une unité de mesure pour exprimer une évaluation de l’effort total qui sera exigé pour entièrement mettre en œuvre un article de l’arriéré de produit (du « Product Backlog ») ou autre travail.

Quand nous évaluons avec des «Story Points», nous assignons une valeur de point à chaque article de l’arriéré de produit. Les valeurs brutes que nous assignons sont sans importance. Ce qui importe sont les valeurs relatives. Une histoire qui est assignée un 2 devrait représenter deux fois plus qu’une histoire qui est assignée 1. Elle devrait aussi être les deux-tiers d’une histoire qui est évaluée à 3 «Story Points».

Au lieu d’assigner 1, 2 et 3, cette équipe pourrait avoir assigné 100, 200 et 300. Ou 1 million, 2 millions et 3 millions. Ce sont les valeurs relatives qui importent, pas les chiffres isolés.

Qu’est-ce qui entre dans un « Story Point » ?

Parce que les «Story Points» représentent l’effort pour développer une histoire utilisateur, l’évaluation d’une équipe doit inclure tout ce qui peut affecter l’effort.

Cela pourrait inclure :
  • Le travail pour faire
  • N’importe quel risque ou incertitude dans la réalisation du travail
  • La complexité du travail

En évaluant avec des «Story Points», assurez-vous de considérer chacun de ces facteurs. Voyons comment chacun impacte l’évaluation d’effort donnée pour l’histoire en question.

Le travail pour faire

typingCertainement, s’il y a plus à faire pour réaliser quelque chose, l’évaluation d’effort devrait être plus importante. Considérez le cas simple de développer deux pages Web. La première page a seulement un champ et une étiquette demandant à entrer à un nom. La deuxième page a 100 champs qui attendent aussi à être simplement remplis d’un peu de texte.

La deuxième page n’est en rien plus complexe. Il n’y a aucune interaction entre les champs et chacun d’eux n’est rien de plus qu’un peu de texte. Il n’y a aucun risque additionnel sur la deuxième page. La seule différence entre ces deux pages est qu’il y a plus à faire pour la deuxième page.

On devrait donc donner plus de «Story Points» à la deuxième page. Cela ne mérite probablement pas 100 fois plus de points bien qu’il y ait 100 fois plus de champs. Il y a, après tout, des économies d’échelle et peut-être que le développement de la deuxième page est seulement 2, 3 ou 10 fois autant d’efforts que la première page.

Risque et incertitude

"Image courtesy of Stuart Miles / FreeDigitalPhotos.net"

« Image courtesy of Stuart Miles / FreeDigitalPhotos.net »

La quantité de risque et incertitude dans un article d’arriéré de produit devrait affecter l’estimation en «Story Points» donnée à l’article.

Si on demande à une équipe d’évaluer un article d’arriéré de produit et le demandant est peu clair sur ce qui sera nécessaire, cette incertitude devrait être reflétée dans l’évaluation.

Si l’exécution d’une fonction implique le changement d’un morceau particulier de code ancien, fragile et qui n’a aucun essai automatisé en place, ce risque devrait être reflété dans l’évaluation.

Complexité

On devrait aussi considérer la complexité lors d’une évaluation de «Story Points». Repensez à l’exemple précédent de développer une page Web avec 100 champs de texte insignifiants sans interactions entre eux.

Pensez maintenant à une autre page Web, elle aussi avec 100 champs. Mais certains sont des champs date avec des gadgets de calendrier qui s’affichent en surimpression. Certains sont des champs de texte formatés comme des numéros de téléphone ou des numéros de sécurité sociale. D’autres champs ont des validations comme avec des numéros de carte de crédit.

Fournir mes informations bancairesCet écran exige aussi des interactions entre des champs. Si l’utilisateur saisit une Carte Visa, on montre un champ CVV à trois chiffres. Mais si l’utilisateur saisit une carte d’American Express, on montre un champ CVV à quatre chiffres.

Bien qu’il y ait toujours 100 champs sur cet écran, ces champs sont plus difficiles à mettre en œuvre. Ils sont plus complexes. Ils prendront plus de temps. Il y a plus de chance que le développeur fasse une erreur et doive repasser dessus et la corriger.

Cette complexité complémentaire devrait être reflétée dans l’évaluation fournie.

Considérez tous les facteurs : Travail, Risque et Incertitude et Complexité

story-pointsIl peut sembler impossible de combiner ces trois facteurs en un chiffre et le fournir en tant qu’évaluation globale. C’est cependant possible parce que l’effort est le facteur d’unification. Les experts considèrent combien d’effort sera exigé pour réaliser le travail décrit dans un article d’arriéré de produit.

Les experts considèrent alors combien d’effort inclure pour prendre en compte le risque et l’incertitude inhérentes à l’article d’arriéré de produit. D’habitude, ceci est fait en considérant le risque d’apparition du problème et l’impact si le risque survient vraiment. Ainsi, par exemple, plus d’effort sera inclus dans l’évaluation pour un risque consommateur de temps qui va probablement arriver que pour un risque mineur et peu probable.

Les experts considèrent aussi la complexité du travail à faire. Le travail complexe exigera plus de réflexion, pourra exiger une expérimentation plus empirique, peut-être plus d’interactions avec le client, pourra prendre plus longtemps à valider et avoir besoin de plus de temps pour corriger des erreurs.

Ces trois facteurs doivent être combinés.

Cfinionsidérez tout dans la définition de fini (« done »)

Une évaluation de «Story Points» doit inclure tout ce qui est impliqué dans l’obtention d’un article d’arriéré de produit entièrement fini. Si la définition d’une équipe de « fini » inclut la création des tests automatisés pour valider l’histoire (et ce serait une bonne idée), l’effort de créer ces tests devrait bien sûr être inclus dans l’évaluation de «Story Points».

Les «Story Points» peuvent être un concept complexe à saisir.

Mais l’effort de bien comprendre que les «Story Points» représentent tout l’effort nécessité par le travail, la complexité du travail et tout risque ou incertitude dans le travail le vaut tout aussi pleinement.

Essayez Bubble Plan !

Essayez Bubble Plan !

Quels autres conseils prenez-vous en compte dans l’évaluation des « story points » ?

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

évaluation des fonctionnalités logicielles telles que perçues par les utilisateurs grâce aux points de fonction

31 Oct

Le Point de Fonction n’est pas la panacée en matière d’estimation logicielle mais il permet d’établir un référentiel compréhensible par tous !

Cet article a été écrit il y a déjà plus de 5 ans par Jean-Baptiste Jourdant, consultant-formateur et Responsable du département Management de projet pour CSP Formation et partenaire de DantotsuPM.

Le chef de projet informatique Maîtrise d’OEuvre (MOE) client : « Avec cette méthode d’évaluation des charges avec les points de fonction (PF), on croit que tout est résolu, mais le prestataire fait ce qu’il veut avec tous ces ajustements, et on n’est pas plus avancé. »

Le chef de projet SSII : « Depuis qu’ils nous demandent des cotations en PF, on n’a plus de marge de manœuvre. En plus, on ne maîtrise pas les coefficients de productivité, alors on s’engage les yeux fermés, et puis on est coincé. »

La théorie synthétisée

Les PF sont une méthode d’évaluation des fonctionnalités logicielles telles que perçues par les utilisateurs (finaux, administrateurs métiers) de l’application. A travers différents composants (groupes de données, transactions) l’application est cartographiée puis valorisée en nombre de PF.

Puis, à l’aide d’un coefficient de productivité (nombre de PF produits par homme-jour), on calcule la charge estimée du projet.

Intérêt

curiositéLe PF n’est certainement pas une panacée universelle. Toutefois, il permet d’établir un référentiel compréhensible par tous les interlocuteurs de la chaîne de production.

La Maîtrise d’OuvrAge (MOA) voit ses fonctionnalités (disséquées, certes),

la MOE client va disposer d’une base de comparaison entre ses différents projets (à manier avec précaution),

la MOE SSII va disposer d’une image fonctionnelle « anticipée » de ses composants techniques, et faire valoir directement les carences éventuelles.

Les éléments variables

Les différents éléments suivants sont évalués pour prendre en compte les spécificités.

  • PRODUIT : nouveauté logicielle, complexité du langage, progiciel, niveau d’ergonomie ou de sécurité demandée, réutilisation du code, …
  • PROJET : Organisation de l’équipe (plateau de développement unique ou éclatement de la réalisation (off-shore), niveau de compétences des acteurs, urgence planning, …
  • MODÈLE DE PRODUCTION : Répartition des activités entre le client et le prestataire (RTU-Réalisation & Tests unitaires, conceptions, tests d’intégration, pilotage, prise de risques, …)
Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

Processus de calcul des charges

calculerEntre la fonctionnalité et les charges, le chef de projet passe par plusieurs étapes :

  1. Cartographie : Nombre de PF dits bruts
  2. Ajustements produits : Nombre de points de fonction ajustés
  3. Utilisation du ratio de productivité standard : Charge nominale
  4. Intégration des spécificités projet (périmètre RTU) : Charge brute
  5. Prise en compte du modèle de production : Charge nette

Exemple

1° Cartographie fonctionnelle =>100 PF Bruts

2° Ajustement produit (sécurité, techno), +20% =>120 PF Ajustés

3° Productivité nominale (REX), 2 PF/HJ =>Charge = 60 HJ

4° Efficacité projet (off-shore), 0,8 =>Charge brute = 75 HJ

5° Activités complémentaires (Conception, doc), +50% => 112,5 HJ

Un ou des ratios de productivité ?

Finalement, dans la méthode, pour passer à l’étape suivante, on utilise un ratio qui mesure la contribution de chaque catégorie.

Et pour une productivité nominale de 2 PF/HJ, on a en réalité entre les PF bruts et la charge nette, une productivité globale de 0,88PF/HJ : 100 PF / 112,5 HJ

CSP est partenaire de DantotsuPM

CSP est partenaire de DantotsuPM

Recommandations

  • CONTRAT : C’est votre contrat qui fait foi. Précisez le ratio de productivité sur lequel vous vous appuyez. Et attention aux engagements préliminaires quand vous ne disposez pas de références.
  • MARGE DE MANŒUVRE : Soyez clair entre clients et fournisseurs sur les éléments variables et cadrer leur influence.
  • CAPITALISATION : C’est le secret de la fiabilisation de vos ratios de productivité !
Essayez Bubble Plan !

Essayez Bubble Plan !

Enregistrer

Enregistrer

le redressement de projet nécessite des qualités et approches spécifiques chez le chef de projet

11 Oct

« Je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès », Rebecca Winston

J’avais publié ce billet il y a 6 ans et il me semble toujours autant d’actualité. Aussi me suis-je permis de le reprendre pour en améliorer la forme et clarifier certains messages clés.

Lessons from a Turn-Around PM billet de Rebecca Winston, JD, Past PMI Chair et PMI Fellow

magicCertaines des leçons que j’ai appliquées, je les ai apprises au prix d’un certain nombre de cicatrices et de l’observation d’autres de chefs de projet que j’ai rencontrés ou avec lesquels je suis en relation. Il n’y a aucune formule magique ni nec plus ultra; Seulement quelques leçons relativement simples qui démentent la difficulté avec laquelle elles sont mises en œuvre.

D’abord, je ne crois pas que quelqu’un soit né sachant comment mener une équipe de projet vers le rétablissement et le succès. Je ne suis pas ni n’ai rencontré non plus le chef de projet de redressement qui connaisse en fin de compte la réponse sur comment transformer un projet dysfonctionnel ou en échec. Cependant, j’ai appris de nombreuses leçons.

1. Croyez en vous.

business success self confidenceNotez bien que je n’ai pas dit croire que vous avez toutes les réponses parce que vous ne les avez pas. Mais vous devez croire sincèrement que vous pouvez faire le job. Si vous ne le croyez pas, qui devrait croire en vous, qui vous donnera une apparente confiance, un sens de la direction et un objectif ?

2. Ne dénigrez pas votre prédécesseur.

Vous faites face à plusieurs pièges si vous vous engagez dans la diffamation du chef de projet précédent. On ne sait jamais qui dans l’équipe peut être leur ami et peut répéter vos déclarations à l’ancien chef de projet. Certaines de ces déclarations peuvent être vraies, d’autres peuvent seulement refléter votre opinion et certaines peuvent s’avérer ne pas être correctes. Vous ne connaissez pas tous les problèmes auxquels s’est confronté le précédent chef de projet. Tout que vous avez sont vos impressions et observations, toutes deux vues par vos yeux et non pas les siens au moment où ils les exécutaient.

De plus, critiquer le chef de projet précédent devant ses pairs peut vous couper d’un précieux réseau. Vous pouvez avoir besoin des autres chefs de projet dans l’organisation pour tester vos idées, questionner la signification et la mise en œuvre de procédures internes, découvrir comment supprimer des points de blocage connus et autres sujets. Beaucoup de ces chefs de projet peuvent vivre dans la crainte d’être les prochains éliminés s’ils trébuchent sur leurs projets.

Oh et n’oubliez pas que la personne qui est votre manager peut avoir été le manager du précédent chef de projet. Il peut même l’avoir embauché. Critiquer le chef de projet précédent peut mettre en doute leur bon jugement.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

3. Soyez focalisé sur faire avancer le projet.

ProgressLa plupart des chefs de projet n’ont pas d’yeux derrière la tête. Les yeux servent à regarder, soit vers l’avant, soit derrière soi. Regarder derrière soi ne change pas le projet et peut vous empêcher de trouver les solutions nécessaires pour résoudre les problèmes. Cela peut aussi vous condamner à revivre dans les risques du passé.

Bien sûr, il faut comprendre ce qui s’est passé et les indicateurs précédents, mais rester dans ce mode ne permet pas à l’équipe d’avancer. En matière de leadership, l’équipe de projet va suivre le chef de projet qui avance sans faire de blocage sur le passé.

4. Croyez en l’équipe.

équipe projet/businessNe commencez pas par remplacer des membres de l’équipe par des personnes avec lesquelles vous vous sentez à l’aise. Assurez-vous de bien analyser votre équipe et de lui donner du temps. Les changements causent une mise en doute de l’équipe et les membres restants peuvent devenir moins productifs qu’ils ne l’étaient ou ne pourraient l’être.

Vous, en tant que chef de projet, devez comprendre que, alors que vous vous sentez à l’aise avec de certains individus, le défi d’accroître le pool des talents avec lesquels travailler est plus important. Ils apporteront de nouvelles idées, une perspicacité de projet, la compréhension des risques tant antérieurs que futurs. Certains peuvent avoir des connexions avec des sponsors, des clients, des fournisseurs et autres personnes nécessaires au succès du projet.

Essayez Bubble Plan !

Essayez Bubble Plan !

5. Ayez un plan.

successLa leçon 5 est quelque chose de familier pour la plupart des chefs de projet : avoir un plan. Le plan devrait avoir reçu les avis de l’équipe de projet comme tout plan de projet, mais il devrait être vendu comme le plan vers le succès. Une communication positive est exigée. Le martelage du manque de réussite ou de progrès passés ne réunira pas l’équipe autour de l’esprit de succès. Tant vous-même que l’équipe devez croire que le succès peut être atteint et qu’il le sera dans les paramètres donnés pour le projet.

6. Renégociez.

Vous êtes nouveau et avez de nouveaux besoins, peut-être quelques nouveaux prérequis, ou de nouvelles parties prenantes. N’ayez pas peur de soumettre des demandes de renégociation. Elles peuvent être conduites selon des styles différents, des besoins de communication différents, et avec une compréhension des leçons qui ont été apprises jusqu’à présent sur le projet.

Méta Projets Management est partenaire de DantotsuPM

Méta Projets Management est partenaire de DantotsuPM

7. Communiquez, communiquez et communiquez encore un peu plus !

bonhom-courrierPeut-on le répéter suffisamment ?

Voici une leçon du management de projet en général, mais qui devient encore plus nécessaire dans un projet de rétablissement.  Des parties prenantes diverses, incluant les membres de l’équipe, devront être rassurées. Elles devront recevoir plus d’informations au moins pendant quelque temps, une meilleure compréhension des risques et des stratégies de management et d’autres sujet sur lesquels elles peuvent vouloir fournir des informations. De temps en temps, on peut estimer que le chef de projet sur-communique. Ce besoin de sur-communication peut diminuer avec le temps et en fonction du temps restant pour terminer le projet.

8. Soyez créatif.

Le chef de projet de redressement ne peut pas toujours compter ce qu’il a fait dans le passé. Il devra créer de nouveaux rapports, délivrer ces rapports de nouvelles manières, construire un esprit d’équipe différent, utiliser de nouveaux canaux de communication, ou stimuler l’équipe à être plus créative et innovatrice. Parfois cela peut être aussi simple que de ne pas amener des croissants pour la réunion d’équipe, mais de fournir à la place un jambon-beurre au petit-déjeuner. Le bruit créé par un changement aussi simple peut mener à une conversation qui rende le nouveau chef de projet plus réel.

inciter-l-equipe-a-etre-plus-creative-et-innovatrice9. Restez en contact avec votre réseau.

networkBien sûr, cette recommandation s’applique à tout chef de projet, mais je l’ai trouvée encore plus importante en menant un projet de redressement.  Vous aurez besoin d’une caisse de résonance. Il y aura des jours sombres et énervants; des jours où vous sentirez que vous serez le prochain chef de projet à ne pas trouver le chemin vers l’objectif. Votre réseau personnel vous écoutera, vous encouragera et vous offrira peut-être des solutions que vous pourrez vous approprier et utiliser.

10. Ne pensez pas que ce projet sera comme le précédent.

De nouveau une leçon générale de management de projet, mais qui prend une nouvelle signification sur un projet à redresser.  Certains aspects peuvent être similaires, mais ces projets n’incluaient pas cette équipe projet, les risques qui ont été rencontrés et leurs impacts, ou les parties prenantes, pour n’en citer que quelques-uns. Déclarer que ce projet est comme un autre que vous avez récemment réalisé transmet à l’équipe un manque de singularité de leur projet et les fera se questionner sur pourquoi ils ont échoué. Hors, les faire se mettre en cause personnellement plus qu’ils ne le font déjà est contre productif.

de bons outilsIl y a ici beaucoup de leçons. Nombre d’entre vous en transportent déjà d’autres dans leurs bagages de PM. J’espère que certaines de celles mentionnées ici peuvent être ajoutées à votre boîte à outils.

De même qu’un chef de projet devrait toujours être en mode apprentissage, votre boîte à outils devrait être en enrichissement permanent.

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

13 Octobre – Webinar (APMG) – Take control of your projects!

7 Oct

Project Planning & Control: Take control of your projects!

There has been very little guidance for practicing and aspiring project planning and control professionals to gain understanding of best practice, and how to apply it, until now…

Partenaire de DantotsuPM

Partenaire de DantotsuPM

The “Planning, Scheduling, Monitoring and Control – The Practical Management of Time, Cost and Risk” guide – published in 2015 – was developed by the UK Association for Project Management’s Planning, Monitoring and Control Specific Interest Group (SIG).

apmg-project-planning-control

Details on this certification

The guide is written in plain English – so even if this is your first experience in the field of planning and controls you should feel comfortable reading, understanding and working towards success.

The guide is supported by APMG International’s Project Planning & Control™ training and certification scheme. This webinar will provide a detailed overview of the guide and supporting training & certification. With some first-hand examples, we will look at the history behind the guidance and the benefits to both the organisation and individual.

Details and registration

%d blogueurs aiment cette page :