« Dites-moi, je vous prie, de quel côté faut-il me diriger ? »
« Cela dépend beaucoup de l’endroit où vous voulez aller, » dit le Chat.
« Cela m’est assez indifférent, » dit Alice.
« Alors peu importe de quel côté vous irez, » dit le Chat.
Alice au pays des merveilles
Si vous n’avez aucun plan, aucune feuille de route produit, aucun plan de livraison, aucune évaluation de quels obstacles vous rencontrerez le long du chemin, aucune évaluation de l’effort et des coûts pour atteindre votre destination, aucune évaluation des attributs d’efficacité et de performance nécessaires pour répondre aux besoins du client, vous finirez comme Alice.
Sur le chemin vers nulle part
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Les commentaires reçus couvrent différents aspect de cette organisation dans leur travail: Planning, suivi, gestion des interruptions, méthodologie, anticipation, gestion du temps, outils tels que checklist et timeboxing…
La méthode Kanban adaptée à la planification de projet présente en effet de réels atouts
Louis Marie RESSEGUIER, PMO consultant au sein du cabinet expert IQar dans l’accompagnement et le conseil de la gouvernance des portefeuilles projets, vous partage ses convictions sur un volet clé de la gestion de projets : la planification de projet !
Quand on évoque la gestion de projet et particulièrement quand on s’intéresse à la phase de planification des projets plusieurs mots clefs peuvent revenir : PERT, Gantt, Kanban…
Ces mots font référence à des méthodes de planification ou de représentation de la planification du projet. Si la démarche de planification consistant à déterminer le chemin critique en passant par la méthode PERT puis à représenter de manière visuelle la planification via l’outil diagramme de Gantt est classique, elle n’en présente pas moins une certaine forme de complexité.
Nombreux sont nos clients qui nous reçoivent avec leurs visages déformés par la douleur au moment d’aborder ce sujet et de leur niveau actuel de leur art en la matière !
Pas de panique ! Pour y remédier dans le cadre des organisations qui débutent en gestion de projet ou qui ne sont confrontées qu’à des projets peu complexes, planifier à l’aide d’une adaptation de la méthode Kanban peut apporter de nombreux avantages.
On vous donne aujourd’hui les 5 principaux !
1/ Simple : Cette méthode est compréhensible et accessible pour le plus grand nombre. Elle se résume à déplacer des post-it (virtuels) dans un tableau en phase de réalisation et à exprimer la feuille de route du projet sur des post-it (virtuels) dans un tableau en phase de planification.
Le Drag and Drop de la planification, on adore !
2/ Visuel : C’est en effet une méthode très visuelle. On repère en un seul un coup d’œil l’avancement du projet, le nombre d’actions à réaliser. En cela, le KANBAN se révèle être un formidable outil de communication complémentaire du Gantt !
Utilisez-le à volonté, ne nuit pas à la santé…de votre Projet !
3/ Universel : Cette méthode est très utilisée et connue dans de nombreux secteurs d’activité et ne demande pas, pour être mise en œuvre, une conduite du changement drastique.
Kanban, une planification à portée de mains…de clics !
4/ Agile : Cette méthode est nativement compatible avec les méthodes agiles comme « scrum » et permet de les outiller avec succès puisqu’elle permet d’illustrer à merveille la gestion d’un « sprint ». En phase de planification un « planning poker » sera facile à réaliser grâce à ce support.
Le Kanban c’est SMART non ?
5/ Compatible : Cette méthode n’empêche pas de la coupler avec le diagramme de Gantt pour l’aspect visuel des délais en planification puisqu’un outil PPM comme SuiteProG, application SaaS développée par IQar, permet déjà de passer pour le plan d’action d’un projet de la vue Kanban à la vue Gantt (en fonction des dates des actions du Kanban) automatiquement.
Agile et docile le Kanban… demandez une démonstration de SuiteProG !
Pour conclure, la mise en œuvre d’une méthode Kanban pour la planification de vos projets, peut être un véritable vecteur de simplification de cette phase incontournable de la vie du projet qu’est la Planification.
Cette méthode peut également s’avérer être un formidable levier d’aide à la conduite du changement dans certaines organisations : notamment celles désireuses de bénéficier des avantages du mode projet tout en adaptant par étapes les modes de travail de ses collaborateurs pour faciliter l’adhésion et le succès de la mise en place de la démarche.
CertYou est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Le diagramme de Gantt est un centenaire depuis cette année !
À fin du 19ème siècle, aux États-Unis, des projets gouvernementaux à grande échelle fournirent l’impulsion pour prendre les décisions importantes qui sont devenues la base de la méthodologie de management de projet tel que la ligne de chemin de fer transcontinentale, dont la construction a commencé dans les années 1860.
Soudain, les dirigeants d’entreprise se sont trouvés face à la tâche intimidante d’organiser le travail manuel de milliers d’ouvriers et le traitement et l’assemblage sans précédent de quantités de matières premières.
Henry Gantt
Henry Gantt a étudié en détail l’ordonnancement des opérations dans le travail et est plus célèbre pour avoir développé le Diagramme de Gantt en 1917 lors de la préparation de l’entrée en guerre des États-Unis d’Amérique.
Le diagramme de Gantt est un type populaire de graphique qui illustre un échéancier de projet et est devenu une technique commune pour représenter les phases et les activités d’une structure de découpage du travail de projet, ils peuvent donc être compris par une très large audience.
Bien que maintenant considéré comme une technique de représentation graphique banale, les diagrammes de Gantt étaient tout à fait révolutionnaires au moment où ils ont été introduits. Ils ont été employés sur des projets d’infrastructure majeurs incluant le Barrage Hoover près de Las Vegas et le réseau autoroutier inter-états des USA et sont encore acceptés aujourd’hui comme un outil important dans les projets.
Microsoft est Partenaire de DantotsuPM
Hélas, Henry Gantt, mort 2 ans seulement après l’invention de ce mode de représentation des plannings n’aura jamais vu combien son invention serait critique au travail de très nombreux chefs de projets.
Il avait conçu ces diagrammes afin que les contremaîtres et autres superviseurs puissent rapidement savoir si la production respectait le planning.
Tous les logiciels modernes de management de projet continuent d’embarquer cette fonction critique.
Microsoft est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Dave Gray, co-auteur de Gamestorming (Jouer pour innover), décrit en 3 minutes comment utiliser cet matrice.
L’approche peut s’appliquer à votre liste de choses à faire ou « To Do List » au travail et « Honey Do List » à la maison. Mais aussi en outil de priorisation de groupe pour un arriéré de produit si vous travaillez en mode Agile ou une liste de fonctionnalités.
Comme les choses à faire et prioriser seront sans doute légion en cette période de rentrée, pourquoi ne pas essayer ce petit outil ?
Microsoft est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Assomption: Acte d’assumer, de prendre à son compte un risque avec toutes ses implications.
« Nous posons, en outre, que l’assomption du risque n’est pas une activité productive par elle-même; c’est le risque surmonté, éliminé, qui permet un accroissement des valeurs ajoutées dans la firme et du produit réel dans l’économie nationale. » Perroux
Alors, comment identifier les assomptions stratégiques ? Voici ce que ce billet nous propose.
L’un des outils les plus importants pour transformer une vision en résultats est de manager les assomptions stratégiques. Les techniques décrites ci-dessous sont faciles à suivre, elles ajoutent de la valeur et peuvent vous aider à lancer votre initiative stratégique.
Les basiques
Les assomptions sont des outils pour la planification et la définition de base de l’assomption (dans le contexte de la planification) est :
Les assomptions sont ces facteurs que l’on considère vrais, réels ou certains dans l’objectif de créer une compréhension partagée du plan.
relisez ce billet
Nous DEVONS faire des suppositions quand nous planifions, en utilisant notre meilleur jugement et les données disponibles. Sinon, ce que nous appelons « le plan » est seulement un désir irrationnel et incohérent.
De plus, nous ne pouvons pas rester dans un mode étude : nous devons accepter le risque que nos hypothèses pourraient être fausses.
Heureusement, si nous suivons deux règles de bon sens nous pouvons éviter les erreurs majeures : 1-documentez toujours les assomptions et 2- validez-les toujours pendant l’exécution.
Exemples d’assomptions stratégiques
Des assomptions stratégiques sont les facteurs critiques qui si invalides, causeraient la mort ou des changements significatifs à l’initiative. Par contraste, comparez-les aux hypothèses utilisées dans les estimations qui sont les facteurs à la base de suppositions de coût, de durée, ou de niveau de ressources.
Voici quatre exemples de suppositions stratégiques :
Nous assumons que le marché répondra favorablement à notre nouveau produit et nous gagnerons 10 % de la part de marché de nos concurrents.
Nous assumons que l’organisation ne sera pas acquise par une autre organisation pendant les 12 mois à venir.
Nous assumons que les ingénieurs de développement peuvent résoudre les problèmes d’intégration et de compatibilité.
Nous assumons qu’il n’y aura aucune nouvelle législation significative ni de changement règlementaire important dans notre secteur dans les 12 prochains mois.
Qu’est-ce qui les rend stratégiques ?
C’est que, si elles sont invalides, il y aura de bonnes raisons d’annuler l’initiative ou de la rediriger de façon majeure.
UtilisezM.O.T.R. pour identifier les Assomptions Stratégiques
Il s’avère que vous trouverez les suppositions stratégiques dans 4 domaines :
M arketing : Décrivez la réponse des clients et du marché
O rganisationnel : Décrivez la configuration et la stabilité de l’organisation. Il est difficile de supporter un changement stratégique pendant des réorganisations majeures de l’entreprise.
T echnique : Problèmes techniques et défis qui affecteront la conception et la mise en œuvre de la solution.
R essources : Disponibilité des capitaux, connaissances, compétences et ressources humaines.
Un exemple concret: Comment un dirigeant a testé son équipe de réalisation
J’étais le conseiller d’un dirigeant qui avait personnellement des doutes sur la capacité de l’équipe de mise en œuvre à penser stratégiquement. Il soupçonnait que les réalisateurs avaient un travers « grand système technique » qui les amènerait à la conception d’une solution qui serait inadéquate pour répondre au besoin.
Pendant une « réunion stratégique de préparation à la mise en œuvre » qui impliquait l’équipe et lui-même, nous avons demandé à l’équipe de préparer des questions pour le dirigeant. Ils ont totalement échoué à penser stratégiquement et se sont reposés sur des assomptions usuelles. En fait, ils faisaient plusieurs hypothèses erronées:
L’équipe n’a jamais questionné le climat politique, ses membres ont seulement questionné les dates de livraison.
L’équipe n’a jamais posé de question sur le désir éventuel de pénétrer une niche inexploitée du marché. Les membres ont assumé qu’ils allaient résoudre un problème pour la partie mâture de leur business.
Ce dirigeant a engagé l’équipe à penser plus stratégiquement. J’ai aussi vu des situations où l’équipe est devenue la cible des critiques en raison de leurs mauvaises assomptions.
Un défi majeur de leadership
Les personnels techniques ont été formés pour trouver et appliquer « les bonnes formules ». Cette formation et cet état d’esprit fonctionnent bien dans des domaines qui sont bien délimités. Elle ne marche pas aussi efficacement dans des domaines stratégiques.
Ils font l’erreur de faire des assomptions plutôt que de poser des questions.
Souvent ces hypothèses de travail sont invalides et amènent à de mauvaises solutions et causent des gaspillages de ressources.
Le leader d’une initiative stratégique doit assumer le rôle de responsable de la formation. Cela signifie être curieux, se méfier des erreurs et poser davantage et de meilleures questions.
Et vous, comment identifiez-vous et managez-vous les assomptions stratégiques sur vos projets ? Quelles sont vos bonnes pratiques ?
CSP est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Nous sommes toujours sous la contrainte de délais serrés, parce que le temps est notre actif de plus de valeur.
Si vous faites une promesse, donnez une date. Pas de date, pas de promesse.
Si vous donnez une date, respectez-la.
Si vous ne pouvez pas respecter une date, dites-le tôt et souvent. Un plan B bien préparé est une meilleure stratégie que d’attendre et espérer.
Nettoyez votre propre désordre.
Nettoyez le désordre des autres personnes.
Sur-communiquez.
Questionnez les fondements et la stratégie.
Ne questionnez pas la bonne volonté, les efforts ou l’intention.
« Je le reconnaîtrai quand je le verrai » n’est pas à dire dans le monde professionnel. Décrire et discuter dans l’abstraction est précisément ce que nous faisons.
De grands projets ne sont pas aussi importants que des engagements effrayants.
Si ce sur quoi vous travaillez ne compte pas tout de suite pour la mission, aidez quelqu’un d’autre dans son travail.
NQI est Partenaire de DantotsuPM
Faites des erreurs, possédez-les, réparez-les, partagez les leçons.
Un logiciel bon marché, fiable, public pourrait être ennuyeux, mais c’est d’habitude mieux. Parce que c’est bon marché et fiable.
La hiérarchie d’hier n’est pas aussi importante que la structure de projet d’aujourd’hui.
Verrouillez les choses qui doivent l’être, laissez de la souplesse dans la mise en œuvre jusqu’à ce que vous compreniez comment elle peut être réalisée.
Majoritairement, nous faisons des choses qui n’ont jamais été faites auparavant, donc ne soyez pas étonné d’être étonnés.
Mettez plus de soin.
Si un externe peut le faire plus rapidement et moins cher que nous ne le pouvons en interne, n’hésitons pas.
Recherchez toujours des ressources externes. Un meilleur carnet d’adresse reste meilleur, même si nous n’avons désormais plus de carnet d’adresse traditionnel.
Parlez à tout le monde comme s’il était votre patron, votre client, le fondateur, votre collaborateur. C’est tout comme.
Ça marche parce que c’est personnel.
CSP est partenaire de DantotsuPM
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Une première vidéo humoristique de notre partenaire Microsoft 🙂 . Elle met en évidence certains des avantages à quitter Excel pour un outil dédié au management de projet et donc bien plus puissant tout en restant simple. En effet, Project permet d’opter pour une planification totalement manuelle si nous le souhaitons.
Microsoft est partenaire de DantotsuPM
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Je ne suis vraiment pas un adepte du travail en regardant l’horloge, et pourtant…
… Je suis certain que la concentration sur une tâche unique et sans interruption pendant un laps de temps suffisant est beaucoup plus productive que de sauter de tâche en tâche ou se laisser détourner de sa tâche par des interruptions intempestives. En effet, de fréquents changements de contexte nuisent fortement à la concentration et à l’efficacité.
Aussi, puis-je facilement reconnaître le bien-fondé des arguments avancés par Red Tani dans son billet en faveur du « timeboxing ».
Le «Timeboxing» est une technique de gestion du temps qui limite le temps pendant lequel une tâche (ou jeu de tâches) est accomplie. Bien qu’il soit généralement utilisé par des équipes de développement logiciel, de plus en plus de personnes (des designers, des auteurs, des ingénieurs — même des étudiants) l’utilisent pour augmenter leur productivité personnelle. Pourquoi ? Voici cinq bonnes raisons.
1. Gratuit et facile.
Vous n’avez rien à acheter. Le seul gadget dont vous aurez besoin est un minuteur que vous avez probablement dans votre cuisine ou sur votre téléphone portable ou ordinateur. Si ce n’était pas le cas, il existe plein de logiciels gratuits en ligne.
Vous n’avez pas besoin de lire de longs livres ni de suivre d’onéreux séminaires pour l’apprendre.
Bien qu’il y ait beaucoup de variations du «Timeboxing», les étapes de base sont essentiellement les mêmes :
Choisissez une tâche ou une liste de tâches.
Prenez un minuteur et réglez-le sur un temps adapté à la tâche. Inversement, vous pouvez vouloir sélectionner la durée en premier lieu et décider ensuite des tâches que vous pouvez exécuter pendant ce laps de temps.
Démarrez le minuteur et concentrez-vous sur l’exécution de la tâche. Évitez toutes les distractions et interruptions.
Quand le minuteur sonne (ou clignote ou vibre), arrêtez de travailler. Idéalement, vous devriez faire confiance au dispositif pour vous dire que le temps imparti est écoulé plutôt que de vous interrompre pour vérifier l’heure de temps à autre.
Récompensez-vous avec un plaisir, une activité agréable, ou simplement un repos bien mérité. L’activité et le repos peuvent eux-aussi aussi être limités dans le temps.
Rebouclez autant de fois que nécessaire.
2. Flexible et personnalisable.
Les étapes listées ci-dessus peuvent toutes être ajustées. Pour ceux qui souffrent de perfectionnisme excessif ou de procrastination, la durée peut être réduite de quelques minutes pour rendre la tâche moins intimidante. D’autre part, les drogués du travail peuvent utiliser le « timeboxing » pour limiter la durée de travail, rendant ainsi le travail moins stressant.
Quand on en vient au choix et à la description des tâches à limiter dans le temps, vous pouvez être très spécifique (“Écrire une description en 100 mots de mon personnage principal”) ou plus vague (“Réaliser un certain progrès sur mon roman”), c’est à vous de choisir.
Le « timeboxing » peut aussi être utilisé pour des activités autres que le travail. Vous pouvez limiter dans le temps les tâches ménagères pour les transformer en jeux (“Ranger mon bureau en moins de dix minutes. Prêt, partez!”). Vous pouvez aussi limiter dans le temps des activités improductives (“Consulter Facebook pendant cinq minutes au maximum.”). Vous pouvez même essayer des variations de « Timeboxing » comme celles de Procrastination Dash et Pomodoro Technique.
Le démarrage sur une tâche est souvent plus difficile que de réaliser la tâche elle-même. Le «Timeboxing» rend les premiers pas moins intimidants. Il est beaucoup plus facile de commencer sur une tâche que vous devez faire pendant seulement quinze minutes que sur une chose où vous devez passer un temps indéfini. Quand vous pensez au travail et au temps d’une façon indéfinie, cela vous parait souvent extrêmement long.
Le choix de la durée du minuteur vous force aussi à choisir une quantité de travail appropriée.
Si vous avez seulement trente minutes pour travailler, vous n’essayerez pas “d’écrire un livre” car “Écrire le premier brouillon du premier chapitre″ est non seulement plus réaliste mais aussi moins intimidant. Posez la question à n’importe quel écrivain.
4. Met votre perfectionnisme sous contrôle.
La procrastination est souvent causée ou au moins liée au perfectionnisme. Non seulement les perfectionnistes ont beaucoup de mal à commencer, mais ils trouvent aussi difficile de continuer et parfois même de finir. Le «Timeboxing» diminue l’aversion envers la tâche et le stress en limitant sa durée.
Mais il y a une autre manière dont la limitation dans le temps peut restreindre le perfectionnisme. En fixant des buts spécifiques à accomplir avant que le temps imparti ne soit écoulé, le perfectionniste est forcé de s’en tenir au suffisamment bon, de donner la priorité aux objets de première nécessité et d’éviter d’aller dans trop les détails. Et si le superficiel ne peut pas être totalement évité, il peut au moins être limité dans le temps. Cela assure que le travail sera fini à l’heure et non ruiné en le peaufinant un peu trop.
5. Vous permet de vous laisser porter par le « Flow ».
Les perfectionnistes rendent le travail trop exigeant en se donnant des buts peu réalistes et souvent avec des standards trop élevés. A l’inverse, quand les buts sont trop insignifiants ou les standards trop faibles, le travail devient trop facile, aboutissant à l’ennui. Quand le travail n’est ni trop facile, ni trop difficile, cela devient aisé, même agréable et fortement productif. Cet état heureux est appelé le « Flow ».
Les conditions qui incitent le « flow » peuvent facilement être créées en se limitant dans le temps :
Un jeu clair d’objectifs : Vous faites une tâche spécifique dans un temps imparti.
La confiance en votre capacité à réaliser la tâche : Tant la tâche que le temps sont librement choisis.
Retour d’information clair et immédiat : Votre concentration pendant ce laps de temps limité garantit que rien n’échappe votre attention et la durée est assez courte pour que vous ne deviez pas attendre longtemps avant de pouvoir évaluer votre travail.
Pendant le « flow », vous concentrez toute votre capacité émotionnelle et intellectuelle sur la tâche à faire, vous permettant de réaliser votre meilleur travail. (Assurez-vous juste que votre minuteur est assez puissant pour vous ramener à la réalité à la fin du temps imparti.)
Devenez un « timeboxer ».
Le «Timeboxing» peut être simple comparé à d’autres outils de gestion du temps, mais comme je vous l’ai montré, ses avantages sont multiples. Il y a d’autres raisons de pratiquer le «Timeboxing»: c’est plus durable, plus facile à prévoir et à mesurer, meilleur pour votre santé. Mais je suis sûr qu’une fois que vous l’aurez essayé, vous trouverez votre propre raison de l’utiliser.
Pourquoi ne lui donneriez-vous pas une chance ?
Faites une liste des tâches que vous avez remis à plus tard. Allez-y! Démarrez votre traitement de texte, mettez votre minuteur et commencez à écrire.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Des retards de projet sont une partie inhérente de n’importe quel projet.
Des 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
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
2. Réévaluez l’état actuel de votre projet et autres retards potentiels
Les 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 !
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
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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 !
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.
On 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.
Le Sprint ne devrait pas être changé après son démarrage.
Les Sprints devraient être de même durée.
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 ?
Un 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.
Dans 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 !
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
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
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éestô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
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..
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 :
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.
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
2) Manque de leadership de la direction générale
Ici 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
La 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
Les 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 !
Un exemple : le principe PRINCE2 ‘focus 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
7) Le manque de compréhension et de contact avec le fournisseur au plus haut niveau de l’organisation
Il 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
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Les «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
Certainement, 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 »
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.
Cet é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é
Il 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.
Considé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 !
Quels autres conseils prenez-vous en compte dans l’évaluation des « story points » ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
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
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
Processus de calcul des charges
Entre la fonctionnalité et les charges, le chef de projet passe par plusieurs étapes :
Cartographie : Nombre de PF dits bruts
Ajustements produits : Nombre de points de fonction ajustés
Utilisation du ratio de productivité standard : Charge nominale
Intégration des spécificités projet (périmètre RTU) : Charge brute
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
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
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 !
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
« 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.
Certaines 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.
Notez 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
3. Soyez focalisé sur faire avancer le projet.
La 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.
Ne 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 !
5. Ayez un plan.
La 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
7. Communiquez, communiquez et communiquez encore un peu plus !
Peut-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.
9. Restez en contact avec votre réseau.
Bien 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.
Il 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
partagez ce billet avec vos amis, collègues et relations professionnelles
Je vais aborder certains des mythes persistants sur le Développement logiciel Agile. Le premier et probablement le plus connu est : « il n’y a aucune planification dans Agile, vous improvisez au fil de votre progression ». Ceci n’est pas du tout vrai.
En fait, je vais aller plus loin et poser une affirmation audacieuse :
Beaucoup de projets agiles font plus de planification que des projets en mode Waterfall / Cascade.
En fait, ils peuvent même faire bien trop de planification. J’espère que les gens qui utilisent les méthodes en cascade toussent et recrachent leur café partout sur leur bureau en réponse à cette affirmation. Décomposons cet argument et expliquons pourquoi je dis ça.
« Les plans ne sont rien. La planification est tout. »
Ceci est un élément essentiel à la compréhension du rôle que joue la planification dans le Développement Logiciel Agile. En « Waterfall », l’idée est que le chef de projet rédige un grand échéancier au début du projet. Souvenez-vous, le contenu est habituellement fixé dès le départ et vous pouvez produire votre Structure de Répartition de Travail dont vous tirez votre plan de ressources (qui fait le travail) et votre diagramme de Gantt (le séquencement dans lequel il est fait) pour livrer ce contenu. Et avec tout ceci, vous pouvez déterminer vos coûts, parce que ces ressources ont des coûts spécifiques.
Puis, tout le monde signe (Oui ,nous aimons tous les signatures, n’est-ce pas !) le grand plan de projet et il est accepté et bloqué. Puis tout le monde vient travailler, selon le grand plan que le chef de projet a produit. Et que fait le chef de projet maintenant ? Il se contente de surveiller, lisant des revues ? Bien sûr que non ! Son travail est de protéger le plan à tout prix.
Les gens continueront à essayer de déplacer des choses, d’ajouter du contenu, d’allonger les délais, de permuter la personne A pour la personne B, de retarder ceci, de supprimer cela, de remplacer cette technologie pour cette autre et le chef de projet doit donc passer beaucoup de temps à :
Essayer d’empêcher tout cela de se produire (parce que le plan est signé), vous vous souvenez ? Ce qui signifie nous ne pouvons pas le changer, OK ?) et
documenter les risques s’il ne peut pas empêcher l’événement, laisser les parties prenantes savoir la catastrophe épouvantable qui s’abattra bientôt sur le projet en raison de ces changements non planifiés.
Ceci ne semble-t-il pas être une situation amusante pour tout un chacun et plus encore pour le chef de projet ?
Pourquoi les projets entrent-ils dans une telle spirale ?
Les projets en cascade s’engagent sur un plan quand il n’y a encore aucune information
Les projets en cascade élaborent un grand plan très complexe au début du projet, quand il y a :
Peu ou pas d’informations sur le travail qui a besoin d’être fait
Peu ou pas d’informations sur le livrable/produit, ce à quoi il doit ressembler et son fonctionnement
Peu ou aucune informations sur les problèmes et risques externes (dépendances, concurrents, partenaires, etc.)
Pas étonnant qu’il y ait autant de changements demandés sur de tels projets : comme les informations commencent à arriver, beaucoup d’entre elles sont en conflit avec le plan, parce qu’il a été basé sur des informations incomplètes (c’est-à-dire il a été composé de conjectures, de suppositions et d’estimations).
Ceci m’amène à une autre de mes citations favorites, cette fois d’un général allemand d’il y a longtemps, Helmuth von Moltke:
« Aucun plan ne survit au contact avec l’ennemi. »
Ce qui peut donner dans notre contexte: aucun plan de projet ne survit au contact avec le projet. Et c’est très bien ainsi, parce que nous ferions mieux de ne pas essayer de tout planifier sur le projet dès le début.
Les projets agiles planifient à plusieurs reprises par petits morceaux
Les projets agiles (utilisant Scrum ou l’une de ses variantes) ne créent pas un grand plan au début, ils font beaucoup de petites activités de planification (à chaque sprint) qui produisent de petits plans (des plans de sprint).
Ainsi au début d’un sprint de deux semaines, vous définissez un plan pour les deux semaines suivantes : c’est appelé la planification de Sprint. À cette réunion, l’équipe sélectionne des articles du Sprint Backlog et discute de combien ils peuvent en compléter pendant ce Sprint et comment le travail sera fait. Plutôt que d’essayer de définir un plan pour un travail que l’on ne connaît pas ou ne comprend pas vraiment, l’équipe élabore un petit plan pour un petit lot de travail qui est :
Bien connu et compris (autrement ce ne sera pas un candidat à entrer dans le Sprint Backlog)
Pouvant être achevé en un sprint (qui est souvent de deux semaines).
Donc vous définissez un petit plan pour une petite quantité de travail, puis vous faites le travail, puis vous faites le plan suivant pour le travail suivant, et cetera, à plusieurs reprises, encore et encore.
Ceci résonne-t-il comme « aucune planification » pour moi ? Pas du tout. Vous commencerez probablement vite à en avoir assez de planifier en suivant cette approche.
Un si petit plan apporte-t-il vraiment de la valeur ?
Vous pourriez penser « mais c’est complètement bidon ce plan, il ne couvre que deux semaines. Le plan en cascade était grand et beau et le Gantt géant expose graphiquement tout ce tout le monde va faire pendant les six mois à venir ! ».
Bien sûr, mais deux points :
Le plan est en grande partie artificiel puisque créé au début du projet, quand personne n’avait vraiment assez d’informations sur le projet (car nous découvrons des informations au fil de notre progression)
Le plan a été créé presque entièrement par le chef de projet, qui ne fera en réalité presque aucun travail lors de la construction du livrable et pas du tout par l’équipe, qui fera presque tout le travail de production du livrable.
Une grande partie de la valeur réside dans la Planification, pas dans le Plan.
Rappelez-vous la précédente citation de Eisenhower.
Les membres de l’équipe se réunissent régulièrement et discutent du travail, combien de ce travail ils pensent qu’ils peuvent faire, combien il restera à faire.
Ceci apportera-t-il plus de valeur que nous l’avions pensé à l’origine ou moins ?
Qu’est-ce qui se révèle être plus facile ou plus difficile que nous ne le pensions de prime abord ?
Ces conversations ont énormément de valeur et aident à guider les développeurs et le propriétaire de produit tout au long du voyage vers l’achèvement du produit ou du projet.
Question: Avez-vous constaté qu’Agile n’apporte pas assez ou bien au contraire trop de planification ?
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.
Microsoft est partenaire de DantotsuPM
I.N.V.E.S.T.
I – Indépendante
N– Négociable
V– de Valeur
E – Estimable
S – Suffisamment petite
T – Testable
Indépendante
Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.
Négociable
Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.
de Valeur
Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.
Estimable
Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».
Suffisamment petite
Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.
Testable
Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.
Découpage vertical ou horizontal
Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.
Des exemples de découpe de « User Stories »
Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »
En tant que client, je peux payer ma commande pour recevoir les produits
Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…
En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.
Et/ou
En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.
Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.
Découpage par flux de travail
revoir mon panier de courses
Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :
Fournir mes informations bancaires
En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.
En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
Recevoir une notification par SMS
En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.
D’autres méthodes
Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :
Visitez le blog Agilistic
par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
par options d’interaction / par plate-forme
par types de données ou paramètres
par scénarios de test
par rôles
par ‘j’optimisemaintenant ‘ contre ‘ j’optimise plus tard ‘
par compatibilité de navigateur
la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.
L’approche classique du chef de projet autodidacte est de dire « quand on doit planifier, on planifie. Et quand on doit planifier, on le fait de façon détaillée, tant qu’à faire ! »
Hors, attaquer directement par la planification détaillée, c’est prendre le risque de se couper d’une réflexion structurelle sur la dynamique interne de son projet.
En effet, le découpage va impliquer tout d’abord un regroupement de tâches a l’intérieur de lots. Ensuite cela va nécessiter pour chacun de ces lots un responsable auquel la réalisation sera déléguée: Objectif spécifique, moyens adaptés, contraintes (qualité, couts, délai)…
Enfin, le choix de structuration de ces tâches va structurer le développement et le suivi du projet. Ces groupement par lots de tâches peuvent refléter une organisation du projet par métier (informatique, processus, opérations, commercial, marketing…), ou par région et pays dans ces régions pour le développement et déploiement de nouveaux produits par exemple, ou par cycle du projet : définir la stratégie, configurer, communiquer, implémenter, tester, former, …
Quelle que soit l’option choisie, elle n’est ni bonne ni mauvaise en soi.
CSP est partenaire de DantotsuPM
Jean-Baptiste préconisait dans ce billet de respecter quelques précautions dans le choix de l’option :
• ÊTRE CHOISIE. Rien de pire qu’un découpage par défaut, par habitude, ou héritée par hasard d’un autre projet (qui pourrait être totalement différent).
• ÊTRE ALIGNÉE avec les enjeux du projet et les objectifs de la société.
• ÊTRE ÉQUILIBRÉE et « COMPENSÉE ». En fonction du choix de découpage, le chef de projet devra probablement ajouter dans le management de son projet les composantes structurellement manquantes. Il doit par exemple mettre en place des processus, outils, réunions… pour garantir la cohérence métier ou technique si le choix de découpage est géographique. Ou, à l’inverse, veiller à impliquer les régions et pays si le découpage du projet est par métier.
Comment bien démarrer?
Jean-Baptiste propose que le chef de projet organise une réunion d’acteurs ou d’experts et suive la démarche suivante:
BRAINSTORMER : Lister toute tâche, activité, lot, thème nécessaire au projet.
REGROUPER: Envisager au minimum 2 possibilités de regroupement des tâches pour avoir un choix.
POSER LES AVANTAGES ET INCONVÉNIENTS de chacune de ces possibilités.
CHOISIR UN DÉCOUPAGE et y incorporer les actions permettant d’incorporer les avantages de la solution non retenue.
CRÉER LES LOTS, les sous-lots ou macro-tâches, puis nommer les responsables de ceux-ci.
Ensuite seulement il sera temps de penser à un planning…
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Dans le monde de l’informatique, beaucoup de praticiens agiles croient que PRINCE2 n’est pas assez flexible pour les demandes business contemporaines. Cependant, pour ceux qui ont passé la formation PRINCE2, la plupart seront conscients que ceci est faux.
En fait, beaucoup de termes de Prince2 sont en soi agiles et peuvent ajouter un niveau de flexibilité à la livraison de tout projet. Pour renforcer cette remarque, voici trois termes qui sont plus agiles que beaucoup ne le pensent.
Partenaire de DantotsuPM
Premier terme Agile – Initiation
A few videos to get started on Agile, Scrum and Kanban
Quand des projets PRINCE2 sont implémentés, ils comptent sur le cas d’affaires pour garantir qu’ils sont justifiables. Il y a aussi les plans qui décrivent ce qui arrivera, les contraintes budgétaires et les stratégies de livraison. Tous ces éléments sont identifiés et décidés pendant l’étape d’initiation.
Le cas d’affaires est l’espace parfait pour articuler une perspective agile et structurer les besoins de projets et planifiant d’incorporer en mode Agile des jeux de fonctionnalités et sorties de produit. Prenez par exemple le management du projet et de l’approche de livraison, les chefs de projet PRINCE2 peuvent tout à fait utiliser des approches agiles comme Scrum et Kanban.
De plus, les plans pourraient aussi être en « time boxing » plutôt que cascade, tandis que le financement pourrait être basé sur les releases plutôt que les étapes techniques traditionnelles liées à l’effort de livraison.
Partenaire de DantotsuPM
En implémentant ces approches dans l’étape d’initiation, le projet peut se concentrer sur la livraison de valeur, diminuant les délais de time-to-market et permettant aux utilisateurs finaux d’utiliser des composants de valeur dès que possible.
Second terme Agile – Work package (Lot de travail)
Une des idées fondamentales des approches Agiles est l’auto-organisation des équipes. Pour que ceci devienne une réalité, les équipes doivent être conscientes de leurs responsabilités et organisées selon des frontières comprises et communicables.
Le lot de travail PRINCE2 n’écarte pas ces principes de base Agile et peut faciliter cette forme d’organisation. Par exemple, les lots de travail peuvent permettre aux praticiens agiles de communiquer aux parties prenantes leurs rôles, responsabilités et autorité. Ceci permettra aux équipes d’être certaines de ce qu’elles doivent faire pour construire et livrer des produits de valeur.
Troisième terme Agile – Tolérance
Avec PRINCE2, le contrôle de la tolérance est sous la responsabilité du chef de projet. La tolérance se réfère à n’importe quelle variation des estimations acceptées lors du cas d’affaires par rapport aux délais, coûts, risques, bénéfices et contenu (périmètre). Si ces tolérances semblent en passe d’être excédées, il est de la responsabilité du chef de projet de remonter ceci au Conseil de Projet pour maintenir un contrôle formel des changements et obtenir une rapide prise de décision.
Partenaire de DantotsuPM
Les méthodologies agiles ont les mêmes approches, bien que sous l’apparence de mécanismes de priorisation. Par exemple, beaucoup de praticiens utiliseront MoSCoW pour ajuster le contenu de leur projet et rester les délais et budget alloués.
Produit Viable Minimum (MVP)
La qualité suit une approche similaire. Prenez par exemple la fabrication d’une voiture. Une approche Agile se concentrerait sur le produit viable minimal – le moteur, le châssis et d’autres fonctions centrales, tandis que les fonctionnalités comme le système de climatisation et le toit ouvrant seront inclus seulement si le temps et les coûts le permettent. PRINCE2 peut faire de même. Il a déterminé les tâches requises et le budget alloué qui est accompagné du contenu. Ceci permet aux projets d’être changés en temps réel pour répondre à des éventualités du marché ou dans le périmètre du projet.
Pour beaucoup, PRINCE2 est toujours l’une des plus, sinon la plus, importante des méthodologies de management de projet disponibles.
Assister à un cours de formation PRINCE2 est une excellente façon de comprendre l’agilité inhérente à cette méthode. C’est aussi une bonne façon d’étendre vos perspectives de travail et d’améliorer votre capacité à livrer des projets rentables dans les temps, avec un focus client et des standards élevés.
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
Enregistrer
partagez ce billet avec vos amis, collègues et relations professionnelles
Si vous n’avez aucun plan, aucune feuille de route produit, aucun plan de livraison, aucune évaluation de quels obstacles vous rencontrerez le long du chemin, aucune évaluation de l’effort et des coûts pour atteindre votre destination, aucune évaluation des attributs d’efficacité et de performance nécessaires pour répondre aux besoins du client, vous finirez comme Alice.
DantotsuPM.com 