articles, méthodes, partages d'expérience et rdv du management de projets et de l'agilité
Est-ce le bon moment pour lancer un nouveau projet ? Devrions-nous renoncer à un projet ? Ou devrions-nous temporiser un peu et positionner ce projet dans le portefeuille de projets à venir ?
Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.
Qu’en pensez-vous et comment traitez-vous ce problème ?Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?
Est-ce périodiquement lors de grands « ménages » saisonniers ?
Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?
CertYou est devenu le centre numéro 1 en volume en France pour la formation PMP® et propose régulièrement les formations PfMP® et PgMP® tellement difficiles à mettre en place !
Au niveau de la business analyse, la certification CBAP® de IIBA a le vent en poupe !
En dehors du management de projets, ITIL® continue d’être adopté par de plus en plus d’organisations et les professionnels passent de multiples certifications.
En effet, de nombreux échanges seront nécessaires par ce média pour parvenir le plus souvent à une compréhension fragmentaire et incomplète du besoin. Les histoires d’utilisateurs Agile comme la description des besoins en méthode Waterfall sont plus efficaces en face à face. Le non verbal est très important et le cycle rapide de questions/réponses que permet l’interaction directe ne saurait être remplacé par l’écrit.
Il s’agit donc de collaborer pour bien comprendre quel est le besoin, i.e. quel problème est à résoudre, plutôt que de se préoccuper du format de l’histoire utilisateur ou du document.
Idéalement, vous devez tous sortir de la séance de travail avec une représentation très claire de ce à quoi ressemblera le produit ou résultat du changement.
Si vous parvenez à identifier des éléments de mesure simples et fiables et à utiliser pour capturer la situation actuelle et la future souhaitée, vous aurez déjà franchi une étape clé.
Il y a tant de managers de projet qui me disent qu’ils ne sont pas estimés même avec tout le bon travail qu’ils réalisent. Ils/Elles respectent les délais des projets, tiennent les budgets, prennent en charge des projets apparemment « impossibles » et gardent toujours le sourire.
Je leur réponds… …bien sûr que non !
On attend tout ceci de vous ! Et c’est très bien que vous puissiez le faire.
Vous voulez démontrer votre valeur de manager de projet ?
Le « Business Acumen » ou compréhension du business est un pré-requis si vous voulez que votre valeur soit reconnue par l’organisation. Définissons un peu le sens du business.
Selon Wikipedia, C’est un concept se rapportant à la connaissance et à la capacité d’une personne de prendre des décisions business rentables.
Pensez-y comme la capacité de voir le business depuis d’autres angles et perspectives. Pensez aux entrepreneurs que vous connaissez et qui réussissent. Ils/elles ont le sens des affaires. Ces leaders comprennent comment voir leur activité sous tous les angles, développer leur stratégie et la mettre en œuvre . C’est aussi ce dont vous devriez être capable en tant que manager de projet.
Pratiquement tous les managers de projet sont impliqué(e)s dans de nombreuses facettes du business simplement de par la nature transverse de leur rôle dans l’organisation. Alors en quoi tout cela a-t-il un rapport avec la communication avec les dirigeants ?
Vous avez besoin de faire de même !
Vous devriez connaître les réponses aux questions suivantes sur votre organisation :
Quels sont les produits et services principaux et quelle est la cible visée par ces produits et services ?
En sachant répondre à ces questions, vous êtes mieux placé(e) pour donner des conseils, suggérer des projets qui devraient être sélectionnés pour atteindre les objectifs organisationnels, devenir un conseiller auprès de l’équipe de direction.
Pensez à combien cela facilitera votre travail avec les parties prenantes et dans la motivation de l’équipe projet.
Qu’en pensez-vous ? Combien de ces réponses connaissez-vous ? Savez-vous comment aller chercher les réponses que vous ne connaissez pas encore ?
Prenez-en la ferme résolution et vous ferez un grand pas vers les rôles de direction et de leadership !
https://www.agilealliance.org/glossary/three-amigos par Alliance Agile
Les trois amigos se réfèrent aux 3 perspectives de base pour examiner un incrément de travail avant, pendant et après le développement.
Business – Quel problème essayons-nous de résoudre ?
Les gens qui tiennent ces différentes perspectives devraient collaborer pour définir que faire et convenir comment ils sauront quand cela sera réalisé correctement. Le résultat final d’une telle collaboration aboutit à une description plus claire d’un incrément de travail souvent sous forme d’exemples, menant à une compréhension partagée pour l’équipe.
C’est aussi la bonne pratique pour les autres. Ils devraient eux aussi passer en revue depuis chacune de ces différentes perspectives les incréments du produit qui ont été mis en œuvre pour s’assurer qu’ils sont corrects.
Le concept des trois amigos a pour objectif de trouver un point d’équilibre entre aucune collaboration entre les personnes qui ont des perspectives différentes et impliquer toute l’équipe dans la discussion de tous les détails de chaque incrément de travail.
Comprendre les parties prenantes du projet et leurs besoins, mais aussi, ceux du sponsor de projet, des donneurs d’ordre, des utilisateurs finaux et des membres de l’équipe projet.
Une meilleure compréhension des autres est à la base du projet qui se donne une chance de réussir.
https://blog.agilistic.nl/understand-your-users-with-an-empathy-map/ par Christiaan Verwijs
La construction de produits formidables exige une compréhension profonde, emphatique de vos utilisateurs. De quoi ont-ils besoin ? Qu’est-ce qui les motive ? Quelle est leur expérience du produit ou processus spécifique ?
Dans ce billet, j’explique comment utiliser des Cartes d’Empathie et des interviews avec des utilisateurs pour construire cette compréhension.
Les Cartes d’Empathie sont un outil simple et puissant pour construire une meilleure compréhension de vos utilisateurs. Il est pas étonnant qu’elles soient les basiques des UX-designers et généralement utilisées dans le Design Thinking. Le nom provient de “Empathie”, qui se réfère à la capacité de comprendre ce qu’une autre personne pense et ressent.
Une recherche Google ramène beaucoup de modèles différents, mais je trouve celui ci-dessous le plus pratique et complet : http://www.eventmodelgeneration.com/empathymap/
Vous pouvez créer une Carte d’Empathie commune à tous les utilisateurs, ou des cartes différentes pour de multiples segments ou utilisateurs individuels.
Dans tous les cas, les meilleures Cartes d’Empathie sont basées sur des données réelles. Pas sur des conjectures ou des suppositions que vous feriez dans votre équipe. Cela signifie qu’une bonne Carte d’Empathie exige de sortir de nos bureaux pour aller discuter avec de vrais utilisateurs en chair et en os.
Interviewez les utilisateurs. Vous pouvez le faire avec l’équipe ou vous pouvez vous séparer en binômes. Assurez-vous que chacun dans l’équipe soit impliqué dans le processus. Prenez des notes pendant l’interview ou enregistrez-le (avec la permission de l’utilisateur, évidemment).Il n’est d’aucune utilité de construire une Carte d’Empathie que l’on ne regarde jamais. Les cartes d’empathie nous permettent de voir notre produit avec les yeux de nos utilisateurs. Cette perspective est facilement perdue au fil du temps, rendant d’autant plus important de garder les utilisateurs tangibles et visibles.
En l’absence d’utilisateurs réels, les Personas et des Cartes d’Empathie sont utiles pendant la Planification ou les Revues de Sprint. Parce qu’ils rendent les utilisateurs tangibles et visibles, ils nous aident à regarder notre produit à travers leurs yeux. Comprendraient-ils cette nouvelle fonctionnalité ? L’aimeraient-ils ? Qu’est-ce qui pourrait être frustrant pour eux ?Partagez ce que votre équipe a appris à travers ce processus lors de leur construction. Postez vos exemples de bonnes et vraies Cartes d’Empathie.
https://www.extremeuncertainty.com/alternatives-planning-poker/ de leontranter
Le Planning Poker est souvent utilisé dans des équipes Scrum (bien qu’il ne soit mentionné nulle part dans le guide Scrum selon la croyance populaire). Mike Cohn l’a popularisé dans son livre “Agile Estimating and Planning“. C’est une technique d’équipe pour collectivement estimer les points d’histoires d’utilisateur. (Pas sûr de ce que cela signifie ? Lisez le « guide to story point estimation »).
Si vous êtes déjà familiers du Planning Poker, n’hésitez pas à sauter directement plus bas “la planification d’alternatives au Planning Poker”. Sinon, continuez de lire pour une explication de comment cela fonctionne et pourquoi les gens l’utilisent.
Disons que vous avez une équipe de sept ou huit personnes, qui ont environ une douzaine d’histoires d’utilisateur dans leur arriéré de produit qu’ils voudraient estimer. Pour le faire via le Planning Poker, chaque personne dans l’équipe aura une certaine méthode pour fournir un chiffre. C’est d’habitude via un sabot de cartes de poker, mais vous pourriez aussi utiliser une app sur votre téléphone. Les chiffres sont d’habitude des nombres de la suite de Fibonacci, une série où chaque nombre est la somme des deux nombres précédents. Donc cela donne 1, 2, 3, 5, 8, 13, 21, et cetera (on ne va d’habitude pas dépasser 21 parce que les histoires d’utilisateur ne devraient jamais être beaucoup plus grandes que d’autres).
L’équipe prend la première histoire de la liste et en discute un moment. Souvenez-vous, une histoire d’utilisateur est écrite comme une déclaration de problème. L’équipe réfléchit ensuite à combien de travail il faudrait pour répondre à cette déclaration de problème, c’est-à-dire mettre en œuvre une solution qui réalise le comportement décrit dans l’histoire.
Estimation de Planning PokerUne fois que l’équipe est prête à estimer, chaque personne choisit un numéro de son jeu de cartes. Ils le font en silence. Puis, chaque personne révèle son évaluation en même temps.
La raison de procéder ainsi est que l’évaluation d’une personne ne devrait pas influencer l’évaluation d’une autre. Si chaque personne fournit son évaluation à son tour, la première personne pourrait choisir une grande (ou petite) estimation, qui pourrait faire changer d’avis d’autres personnes et ainsi biaiser leur évaluation. Le processus est destiné à permettre à chaque personne de fournir sa propre évaluation impartiale et honnête.
Bien sûr, les valeurs sont souvent différentes, ce qui signifie qu’une autre discussion démarre. Il y a parfois alors un autre round d’évaluation. Quelques puristes de Scrum insistent pour que l’équipe continue les rounds d’évaluation jusqu’à ce que chacun arrive au même nombre. Je pense que c’est de la folie et que cela encourage ce que le planning poker devrait empêcher : les gens « forçant » d’autres à être d’accord avec leur évaluation.
Je pense que cela devrait continuer jusqu’à ce qu’un consensus soit atteint, ce qui est d’habitude très clair (et PAS la même chose que la conformité, c’est-à-dire quand chacun a la même valeur). S’il y a une gamme d’évaluations consistant de 2, 2, 3, 3, 5, 5, l’estimation est de 3. Cela ne doit pas être une moyenne exacte, mais une médiane suffit. Et cela ne doit pas être mathématiquement précis. Les évaluations sont essentiellement des suppositions informées. Le processus d’évaluation n’est pas précis donc les évaluations ne le seront jamais et c’est ok.
Vous pourriez vous demander pourquoi vous voudriez des alternatives à le Planning Poker. Ce n’est pas un mauvais système, mais il a quelques problèmes.
Cela peut prendre une longue période de temps pour faire l’évaluation avec le Planning Poker. J’ai vu des sessions de deux ou trois heures et ce n’est pas amusant. Montrer ces cartes est au départ amusant mais cela devient usant vraiment rapidement. Tergiverser sur savoir si quelque chose vaut 2 ou 3 est ennuyeux et irritant et ce n’est pas une conversation de valeur.
La discussion sur quelle carte est bonne ou fausse peut distraire les gens d’une conversation de plus de valeur : la discussion de la solution. Particulièrement, pourquoi quelqu’un estime que quelque chose mérite 2 ou 3 par opposition à une autre valeur.
Certaines personnes pensent que si vous faites ce jeu intelligemment, alors les évaluations elles-mêmes deviennent soudainement plus précises et donc de plus de valeur. C’est complètement faux. Le Planning Poker est une bonne façon d’atteindre un consensus sur des évaluations. Cela ne signifie pas qu’elles soient précises. Il est très possible pour un groupe de personnes d’être dans l’erreur à propos de quelque chose (particulièrement quelque chose de notoirement difficile à évaluer comme la complexité de développement de logiciel).
Il y a quelques alternatives que vous pouvez essayer si vous vous fatiguez du Planning Poker, ou pensez que cela pourrait être mieux.
Au lieu des nombres (Fibonacci ou autres, vous pouvez utiliser des tailles de T-shirt. Petit, moyen, large, extra-large. Cela vous donne une plus petite gamme d’estimations possibles, ce qui signifie que vous obtiendrez moins de désaccords et moins de variance. Vous pourriez penser que les évaluations seront moins précises, mais je ne pense pas qu’elles le seront. Je constate que les tailles de t-shirt sont suffisantes. Vous aurez besoin de quelques références pour ces tailles; utilisez simplement des histoires ou des fonctions précédentes. (J’aime en réalité faire des évaluations de taille de t-shirt et aucune autre estimation d’histoire). Vous pourriez aussi utiliser un jeu plus réduit de nombres (1, 5, 8, 20) ou autre chose pour remplacer les tailles de t-shirt. Mais j’aime le fait que des nombres ne soient pas utilisés. Cela clarifie le fait que ce ne sont pas des mesures et elles ne sont pas précises.
Pour l’estimation précise, vous pouvez utiliser la technique du planning poker, ou la Technique « Affinity Mapping ».
Vous pourriez être familiers avec la technique « Affinity Mapping » car elle est utilisée dans les Rétrospectives de Sprint. C’est une technique pour grouper ensemble des articles semblables. Commencez par créer une série d' »étiquettes » ou de « piles » sur la table : celles-ci pourraient être numérotés selon Fibonacci, ou les tailles de t-shirt, ou des catégories, ou quoi que ce soit. Puis, vous déposez les histoires sur la table comme des cartes. Ensuite, l’équipe déplace collectivement les cartes dans les piles pour les représenter selon leur estimation.
Petite Vidéo de Vincent Drecq, auteur du livre en français « Pratiques de management de projets ».
C’est une technique intéressante, peu commune et peu connue. C’est une manière efficace d’évaluer un grand nombre d’histoires dans un espace de temps très court. Commencez par définir vos points de référence (nombres de Fibonacci, tailles de t-shirt, etc). Créez des piles sur la table selon la technique « Affinity Mapping ». Ensuite, chaque personne est aléatoirement assignée un jeu d’histoires à estimer (peut-être en distribuant les histoires comme si elles étaient des cartes à jouer). Puis, à tour de rôle, chaque personne évalue en silence en plaçant une carte sur une des piles. Alternativement, une personne peut déplacer une carte d’une pile à une autre, si elle est convaincue qu’une estimation est incorrecte.
Continuez à faire ceci jusqu’à ce que toutes les cartes soient estimées. Si une carte est déplacée deux fois, ôtez-la de la table – elle aura besoin d’une discussion séparée après la réunion car il y a un fort désaccord sur son estimation.
L’avantage de cette technique est qu’une équipe peut évaluer beaucoup d’histoires en un très court laps de temps. A utiliser si l’on vous demande d’évaluer 100 histoires (même si je pense que c’est le signe d’un plus gros problème car vous devriez seulement évaluer un ou deux sprints d’histoires Utilisateurs à l’avance). L’inconvénient est que vous sautez ce qui est souvent la partie de plus de valeur : la discussion autour des histoires.
D’autres personnes prennent une position plus extrême. Ils pensent que nous devrions nous débarrasser totalement des estimations ! C’est un mouvement qui est souvent identifié par le hashtag Twitter #NoEstimates. Il a été lancé il y a quelques années par quelqu’un appelé Woody Zuil et est principalement soutenu par un coach Agile nommé Vasco Duarte. Si vous voulez l’essayer, c’est facile : n’abandonnez pas seulement le Planning Poker, abandonnez aussi toute estimation. Vous pouvez alors faire deux ou trois choses :
En ce qui me concerne, je tombe dans le dernier camp. Je ne pense pas que les évaluations d’histoire sont très forte valeur, bien que des évaluations de haut niveau de fonctionnalités soient utiles pour la planification de release (et j’ai constaté qu’elles sont souvent aussi ou plus précises qu’une somme d’évaluations de point d’histoire).
#NoEstimates est un sujet complexe et très controversé et qui mérite une discussion séparée.
Vous pouvez essayer ces techniques et voir ce qu’en pense l’équipe. Assurez-vous de les considérer comme des expériences et recueillez-en les données: L’équipe estime-t-elle que c’est mieux que le planning poker ? Les évaluations se sont-elles avérées de plus de valeur ?
https://www.scrum.org/resources/blog/understanding-complexity par Erwin Van der Koogh
Une des choses les plus importantes à comprendre dans le monde du business (et dans la vie en général) est le concept de complexité. Tandis que nous utilisons les mots compliqué et complexe presque de manière interchangeable dans le parler quotidien, ils signifient en réalité des choses très différentes. Explorons mon modèle favori sur la complexité : Cynefin.
Il existe un certain nombre d’articles et vidéos d’introduction à Cynefin, y compris celle de Dave Snowden, mais certains ne sont pas toujours très accessibles.
Essayons de l’expliquer avec des jeux. Richard Shy a créé une visualisation étonnante de Cynefin dans un de mes cours.
Cynefin parle de quatre types différents de problèmes ou domaines. Évident, Compliqué, Complexe et Chaotique. Nous aborderons ces premiers et couvrirons à la fin le Désordre.
Cynefin est une façon d’appréhender de quel type est un problème est et propose une stratégie de haut niveau pour résoudre ces différents types de problèmes.
L’analogie de jeu pour Évident est le Tic-Tac-Toe, aussi appelé « morpion ». Comme dans le Tic-Tac-Toe, les problèmes Évidents ont un lien de cause à effet clair et prévisible.
La stratégie de haut niveau pour résoudre des problèmes Évidents est « Observer – Catégoriser – Répondre ». Observer n’est rien de plus complexe dans ce cas que regarder la grille. Catégoriser les moyens que nous avons de réduire toutes les combinaisons possibles en sous-ensemble beaucoup plus petit, gérable. Et Répondre faire un déplacement. Tic-Tac-Toe a 255,168 parties possibles, mais nous avons besoin de connaitre seulement quelques règles pour jouer la meilleure partie possible. Prenez le pion de départ, il devrait être placé dans un angle, n’importe quel angle fera l’affaire.
Nous avons regardé toutes les options possibles et calculé la meilleure voie. Ils sont appelés « Best », parce qu’il y a toujours exactement une meilleure réponse.
Le problème évident avec les problèmes évidents est que peu d’entre ceux restent sans réponse. C’est la substance qui est facilement automatisée. Les ordinateurs sont extrêmement précieux pour ce type de travail.
Maintenant, le Tic-Tac-Toe (les Morpions) est un jeu très ennuyeux précisément parce que nous l’avons calculé. Après, les meilleures pratiques vous feront jouer un jeu parfait. Si les deux joueurs jouent un jeu parfait il est un dessiné.
Les échecs sont très différents. Et notre stratégie de haut niveau pour des problèmes Évidents ne nous aidera pas le jeu d’échecs. Quelques mouvements dans un jeu d’échecs et le conseil sont dans une position vous ne l’avez jamais vu dans auparavant. Et plus important encore une différence minuscule dans le conseil fait une différence massive dans le jeu.
Dans des problèmes compliqués le rapport entre la cause et l’effet est prévisible, mais (très durement prévoir. Des problèmes compliqués sont le domaine d’expert, qui est meilleur capable de prévoir ce qui va probablement arriver. Qui est exactement quels joueurs d’échecs supérieurs font. Ils doivent prévoir ce que les mouvements probables de leurs adversaires vont être. Les experts peuvent simultanément considérer des options plus possibles, mais le réduire aussi à un jeu plus petit des scénarios qui exigent plus d’analyse.
Donc la stratégie devient le Observer – Analyser – Répondre. Et parce que c’est la figure impossible de si un mouvement est le meilleur mouvement (sauf la défaite évidemment) il n’y a aucune pratique la meilleure dans le domaine compliqué.
Mais il y a de bonnes pratiques. Les pratiques que l’on considère utile dans de certains contextes. Dans des échecs un exemple est la valeur de vos pièces. Chaque morceau dans des échecs fait associer une valeur avec cela. Et vous voulez toujours la valeur totale de vos pièces pour être plus haut que vos adversaires. À moins que vous ne vouliez que, parce que vous vouliez sacrifier un morceau pour la position de conseil.
Les problèmes complexes sont à nouveau complètement différents. Ce qui les met à part est que le rapport entre la cause et l’effet est seulement évident de manière rétrospective. La métaphore de jeu pour la complexité est le poker. À la différence des échecs, qui sont un jeu de prévision, le poker est le jeu de l’étude. Apprendre quelles cartes vos adversaires ont et comment leurs mains se mesurent à la vôtre. Et la stratégie de haut niveau des échecs ne fonctionne pas pour le poker.
Si vous jouez ma version favorite de poker, le Texas Hold’em, vous pouvez regarder vos propres cartes jusqu’à en perdre le souffle, mais la seule chose que vous allez apprendre est que vos adversaires n’ont pas exactement les mêmes cartes que vous. Donc Sentir – Analyser – Répondre est éliminé comme façon de traiter la complexité.
Ce dont nous avons besoin à la place est Investiguer –Sentir – Répondre. Une investigation est une expérience sans risque. Selon le résultat de cette expérience (Sentir) nous répondons en amplifiant les bonnes et/ou réduisant les mauvaises (Répondre).
De nouveau, prenant l’exemple du poker, l’investigation peut prendre la forme d’une mise. Si vous déposer une mise vous forcez des adversaires à y répondre, en se couchant, répondant ou surenchérissant. Cela peut vous donner de l’information sur leur main. Mais d’autres investigations peuvent être d’attirer l’attention des adversaires, sentir peut être seulement regarder leurs comportements.
Donc la chose la plus importante de la Complexité est qu’il n’y a aucune façon d’apprendre (et ainsi résoudre le problème) sans faire. Réfléchir ne va pas résoudre le problème. Dans les problèmes Complexes, nos pratiques se développent toujours en se basant sur ce que nous apprenons. Dans le poker, même si nous jouerions une partie avec exactement les mêmes joueurs et exactement les mêmes cartes exactes, la partie serait différente. Parce que nous avons appris des choses pas seulement sur le jeu, mais aussi sur nos adversaires.
Le chaos arrive quand il n’y a aucun rapport entre la cause et l’effet ou qu’ils changent très rapidement. Dans ce cas il n’y a aucune raison de réaliser des investigations parce qu’aucune étude ne nous aidera à nous améliorer.
L’analogie de jeu est ici le jeu d’enfants. Quelqu’un qui a déjà joué avec des gosses sait que les règles changent continuellement. Et il n’y a aucune raison d’essayer d’apprendre les règles avant le départ du jeu. Vous devez entrer et jouer avec eux (Agir), tout en vous assurant de l’amusement (Sentir) et en changeant en conséquence (Répondre).
Mais le plus souvent nous terminons dans le Chaos à cause d’une petite crise. Quand cela arrive nous devons très rapidement stabiliser la situation et ressortir du Chaos. Cela arrive tout le temps dans le business, où nous nous reposons fréquemment sur des leaders héroïques et des équipes spéciales pour nous sortir des problèmes.
Les pratiques sont ici Nouvelles.
Le désordre n’est pas un domaine séparé, mais signifie au lieu de cela que nous utilisons le jeu de stratégies avec lequel nous sommes à l’aise au lieu de celles appropriées au problème à résoudre.
Et la malheureuse réalité consiste en ce que la plupart des personnes passent ici la plus grande partie de leur temps.
Chaque fois que je me trouve (ou les gens autour de moi) à passer trop de temps à réfléchir, mon premier instinct est de prendre du recul pour m’assurer que le problème à traiter est Compliqué. Quand les organisations continuent à insister sur les Meilleures Pratiques, je vérifie d’abord si le problème est à portée de main en fait Évident. S’il est Compliqué (ce qui est très probable), nous devrions regarder une myriade de bonnes pratiques et calculer quelles pratiques sont applicables dans quelles circonstances.
Le domaine de la Business Analysis s’est énormément développé sur les dernières années au point que nombreux sont celles et ceux qui le considèrent comme un élément prépondérant dans les projets et programmes.
Les analystes business permettent de produire des descriptions de meilleures qualités des attentes des clients ainsi que de toutes les autres parties prenantes du projet.
Ce standard a pour but de devenir une fondation sur laquelle poser vos pratiques actuelles et les faire évoluer et s’améliorer. Cette base se veut compatible avec les différents types et tailles d’organisations, de domaines industriels et commerciaux ou administratifs.
Bonne lecture et n’hésitez pas à postez vos remarques et commentaires ci-dessous.
PMI is a registered mark of Project Management Institute, Inc.
http://www.johnmaxwell.com/blog/youll-never-find-the-right-answers-if-youre-asking-the-wrong-questions par John C. Maxwell.
“L’esprit non créatif peut discerner les mauvaises réponses, mais il faut un esprit créatif pour reconnaitre les mauvaises questions.”
Sir Antony Jay
Pendant la résolution de problèmes, il est très facile de tomber dans l’ornière de la pensée non créative. Nous pouvons nous concentrer tellement sur les réponses et les solutions que nous perdons de vue la question. Et si nous posons les mauvaises questions, nous terminerons souvent avec de mauvaises réponses.
A quel point votre pensée est-elle créative ? Quand vous êtes face à un problème, vous tournez-vous immédiatement vers les solutions infaillibles que vous utilisez depuis toujours ? Ou ouvrez-vous votre esprit à de nouvelles idées ?
Le Physicien Tom Hirschfield a observé: « si vous ne demandez pas, ‘Pourquoi ceci ?’ assez souvent, quelqu’un demandera, ‘Pourquoi vous ?’ »
The Agile Business Analysis (AgileBA®) Handbook – published by DSDM Consortium – offers useful, practical and comprehensive guidance on the role of the business analyst working in an Agile way.
It also aims to give context to the business analyst role beyond the individual project, in relation to organisational mission and strategy, and to give additional depth and guidance for the business analyst role.
AgileBA highlights techniques that can help the Agile business analyst support the organization in the formulation and reviewing of its strategies. Even if the project-level Agile BA is not directly involved in defining the organization’s strategies, they need to understand the way strategy is formulated and the factors and forces which affect it. This will give them the perspective to ensure that the projects they are involved in have objectives that align with, and support, the organization’s strategic goals.
Business Analysis is crucial to the success and competitiveness of organizations in today’s rapidly-changing environment, enabling the timely delivery of high value, cost-effective solutions. As the project world continues to change, the BA role will continue to be an evolutionary role: embracing Agile is a significant part of this evolution.
The guidance is aimed at aspiring, new and existing Business Analysts, whether new to working in an agile environment or experienced in agile practices. It will also support project managers and product owners working with (or within) agile project teams and other practitioners looking to understand the value and role of business analysts on agile projects.
The handbook is also the official reference material for those undertaking accredited AgileBA training and Foundation & Practitioner level certification.
Ce syllabus définit le niveau de base (Niveau Fondation) pour devenir un Analyste Métier Certifié IBAQB (CBA). IBAQB a développé ce programme en collaboration avec l’Association mondiale pour la qualité logicielle (GASQ).
IQBBA provides you with a certification scheme allowing to gather knowledge and skills necessary for improving your business.
Avec l’introduction de la certification PMI-PBA, le PMI officialise l’importance du travail des BA dans le monde de la gestion de projet. La certification PMI-PBA met en lumière la capacité des professionnels à travailler efficacement avec les différents intervenants pour définir leurs besoins business.
It’s time to become the certified expert your organization needs. If you work with stakeholders in defining requirements, shaping project outputs and driving intended business outcomes, the PMI Professional in Business Analysis (PMI-PBA)® will spotlight your valuable skills.
PMI-PBA is a registered mark of Project Management Institute, Inc.
Le CPRE est un certificat personnel; il vise les individus qui œuvrent avec les exigences et qui ont des attentes élevées en termes de qualité.
L’IREB, pour International Requirements Engineering Board, une organisation à but non lucratif, est le fournisseur du schéma de certification Professionel Certifié en Ingénierie des Exigences (CPRE pour Certified Professional for Requirements Engineering). Le comité de l’IREB est composé de représentants reconnus en ingénierie des exigences, qui viennent de la science, de la recherche, de l’industrie et du conseil.
Le Guide du corpus de connaissances de l’analyse d’affaires appelé BABOK (Business Analysis Body of Knowledge) est le standard reconnu à l’échelle internationale en matière d’analyse d’affaires. Le BABOK est l’ouvrage de référence sur lequel les praticiens peuvent s’appuyer pour mener à bien leurs analyses d’affaires, la plupart du temps dans le cadre de projets liés au système d’information de l’entreprise.
Pour entrer dans les détails, participez à la prochaine conférence BAFS2016 le 3 juin à Genève. Découvrez le programme détaillé de cette édition 2016 : www.bafs2016.org
Jean-Christophe Hamani, Vice-President PMI France
La Business Analyse en tant que « traduction des besoins en exigences » est une discipline indispensable, matérialisée par le business case (cas d’affaire) et le cahier des charges à l’origine des projets. Pour autant, la pression exercée sur les organisations privilégie souvent le « Quand » (les délais) et néglige quelque fois le « Pourquoi » (au fond quelle est la raison business ?) sans oublier le « Pour Quoi » (quel est le vrai produit résultant du projet répondant à ce besoin business ?).
Le PMI rappelle que près de 40% des organisations considèrent un mauvais pilotage des exigences comme étant la cause majeure d’échec sur leurs projets.
Dans un environnement de transformation récurrent des organisations et des contextes, un leader de projet, programme ou portfolio peut-il prendre le risque de rater la cible qu’avait en tête son donneur d’ordre ? Il devient de plus en plus crucial de fournir aux praticiens les outils permettant de sécuriser un alignement de la stratégie avec l’exécution !
Le PMI en a bien compris la nécessité et c’est fin 2014 qu’est lancée la session pilote de la certification PMI-PBA®, qui compte en moins d’un an et demi près de 700 certifiés !
En intégrant la Business Analyse au cycle de vie décrit dans le référentiel PMBOK® Guide, le PMI a donné à cette discipline la dimension qui en fait un facteur clé de succès dans la réalisation des projets.
Fort de ce constat, vous décidez de rajouter cette nouvelle certification à votre actif. Conçue sur le même modèle que le PMP® soit 4 heures d’examen et 200 questions (seuil de réussite à 70%), vous visez et planifiez une fenêtre de trois mois pendant lesquels vous vous consacrerez à la préparation.
Mais êtes-vous éligible ? Il vous faut télécharger le PMI-PBA® Handbook. Il vous appartient d’ouvrir un dossier de candidature à soumettre dans les 90 jours. Votre éligibilité vous sera communiquée dans les 5 jours. Par contre, à partir du moment où vous payez pour l’examen (405 US$ au tarif membre), vous aurez un an pour le passer avec la liberté de choisir la date auprès du centre Prometric (75019). Notez que vous avez trois possibilités de passer l’examen, les deux dernières étant payantes (275 US$). Je vous recommande le test sur PC (Computer Based Test) qui vous permet d’avoir le résultat immédiatement (sans attendre 15 jours).
Pour revenir à l’éligibilité, les deux difficultés principales résident dans la justification d’une expérience de Business Analyse et d’une formation de 35 heures. Cette expérience doit être de trois ans minimum (4500 heures dont 2000 dans un contexte projet) pour un bac + 5. On ne vous demande pas d’avoir été business analyste sur votre CV mais a minima d’avoir exercé une activité de BA en environnement projet. Comme pour le PMP®, vous devez être capable de produire des pièces justificatives en cas d’audit. Souvent la difficulté réside dans la justification de la semaine de formation avant l’éligibilité …
Needs Assessment (18%) – Comment évaluer les besoins business (problèmes ou opportunités) et proposer des initiatives pour consolider le business case
Une large part est consacrée aux outils et méthodes, à l’adaptation de l’effort du BA selon le mode de développement (Cascade vs. Agile) et à l’intégration dans le processus du PMBOK® Guide.
A la différence du PMP®, la préparation du PMI-PBA® se fait sur la base … d’une liste de lecture contenant pas moins de 12 références ! Pas de panique, pour ma part je pense qu’il y a en priorité deux documents que vous devez parfaitement maîtriser :
Ces documents sont téléchargeables gratuitement pour les membres PMI. Cependant, je recommande fortement de travailler sur une version papier.
Je vous recommande également de télécharger le document suivant, qui se rapproche du « Practice Guide » et détaille la partie « Requirement Management » du PMBOK® Guide
Cette certification étant nouvelle, la liste des ouvrages disponibles a l’avantage d’être restreinte. J’ai également acheté un guide qui est très complémentaire du « Practice Guide » (écrit par deux des auteurs du « Practice Guide ») et un test blanc :
Bien entendu, vous avez la possibilité de suivre un cours auprès d’un REP (Registered Education Provider) (une liste de REP partenaires est disponible sur le site du PMI France).
Après une première lecture de ces documents, vous devez commencer à vous entrainer. Les deux derniers documents (le premier comporte un test pour chacun des domaines ainsi qu’un examen blanc de 100 questions) vont vous aider à retenir tous les concepts, notamment les méthodes pratiques, comment et quand les utiliser.
Par contre, il m’apparait absolument indispensable de s’entrainer en conditions réelles sur des bases de questions (je précise que tout l’environnement du PMI-PBA® est en anglais, à la différence du PMBOK® Guide et du PMP®). La plus grande difficulté de l’examen réside dans la capacité à rester frais pendant 4 heures d’affilée. Les questions sont en grande majorité des études de cas, vous devez donc vous préparer à lire un énoncé de plusieurs lignes dont chaque mot compte ! De plus, vous devez choisir la réponse la plus adaptée parmi quatre (généralement deux sont possibles -une plus que l’autre- et deux sont disqualifiées par un mot dans la description).
Aussi, je vous recommande de vous entrainer jusqu’à avoir une bonne marge. Pour ma part, j’ai attendu de réussir une banque de question en conditions réelles à 90% avant de passer l’examen (70% à atteindre). En effet, en utilisant une banque de questions, vous vous habituez au style et vous retrouvez aléatoirement des questions auxquelles vous avez déjà répondu. Par contre, le jour de l’examen, vous serez face à 200 questions inconnues rédigées dans un style différent !
Une fois le précieux label obtenu, que peut-on retenir de cette expérience ?
Cette préparation a été une belle occasion de :
Rafraichir ses connaissances par rapport au PMBOK Guide
Cette certification n’a pas vocation à transformer des praticiens de projet en BA mais plutôt de garantir que nos Managers et Directeurs de projet, programme et portefeuille maitrisent la dimension de Business Analyse, facteur essentiel de réussite.
En conclusion, la certification PMI-PBA®, fort bien faite, offre la possibilité de valider des compétences de type « Strategic and Business Management », compétences critiques pour qui veut entretenir la dimension stratégique du management de projet dont la première vocation est de prodiguer, par l’excellence opérationnelle et la performance, un avantage compétitif à nos entreprises.
N’hésitez pas à me contacter sur jean-christophe.hamani@pmi-france.org
PMI-PBA, PMI, PMP, PMBOK Guide are registered mark of Project Management Institute, Inc.
http://www.projecttimes.com/kiron-bondale/a-project-manager-should-always-keep-an-eye-on-benefits-realization.html par Kiron Bondale
La gestion de la triple contrainte est seulement le service de base, il est grand temps pour les chefs de projet d’aller plus loin.
La préoccupation naturelle qui pourrait être soulevée est que, dans de nombreux cas, le chef de projet est passé au projet suivant alors que le propriétaire de produit (Product Owner) et certaines autres parties prenantes travaillent encore à assurer que le changement requis pour réaliser des bénéfices est bien effectif. Le chef de projet pourrait avoir eu un engagement direct limité avec le personnel qui doit adopter les changements, ou pourrait n’avoir aucune influence sur les facteurs externes qui auraient un impact sur la réalisation desdits bénéfices.
Ceci est tout à fait vrai, et pourtant, si le projet ne délivre pas les bénéfices attendus, le chef de projet va probablement recevoir une partie du blâme.
Ceci ne veut pas dire que les chefs de projet n’essayent pas de poser les bases du réel succès après avoir complété leurs projets. Parfois, la faute pourrait revenir aux propriétaires de produit susceptibles de percevoir de tels efforts du chef de projet comme une intrusion dans leur juridiction. Cependant, ceci n’est en aucune manière une raison suffisante de reculer pour le chef de projet. Si il a une preuve suffisante que la réalisation des bénéfices sera impactée, c’est sa responsabilité de s’assurer que ces informations sont prises en compte.
Pendant l’initiation du projet, le chef de projet devrait prendre le temps de comprendre le cas d’affaires qui soutient le raisonnement du sponsor d’investir dans le projet. Ceci est un des avantages à avoir un chef de projet qui ait un peu d’expertise du domaine. Un chef de projet qui a seulement une compréhension superficielle des processus métier va probablement moins comprendre si certaines suppositions fondamentales sont invalides. Il pourrait éluder des menaces qui auraient un impact sur la réalisation réussie des bénéfices.
Un analyste d’affaire est d’habitude responsable de l’élicitation de besoins et devrait vérifier que les besoins collectés sont directement connectés au cas d’affaire et aux retours attendus. Et, le chef de projet devrait aussi prendre le temps de passer en revue la ligne de bases des besoins comme cela dicte beaucoup de décisions en aval qui peuvent avoir un impact sur le succès de projet. En faisant ceci, le chef de projet est mieux équipé pour supporter l’analyste d’affaire dans la facilitation de la prise de décisions appropriées – quand les changements de portée interviennent plus tard dans la vie du projet.
Pour les projets dont on attend livrer des avantages financiers, le chef de projet devrait non seulement se concentrer sur la définition des coûts du projet, mais devrait aussi passer en revue les coûts opérationnels récurrents et les projections de revenu estimées par le propriétaire de produit et autres parties prenantes. Si les suppositions à la base de ces évaluations ne semblent pas être correctes ou si le chef de projet croit qu’une contrainte clé pourrait avoir été manquée, il devrait partager cette préoccupation.
Réalisation / Construction
Une fois que le travail a commencé pour livrer le contenu approuvé du projet, la plupart des chefs de projet ont tendance à concentrer leurs efforts sur garder le projet sur les rails et manager efficacement des demandes de changements par rapport aux lignes des bases. Pour complémenter ces activités normales de projet, le manager de projet devrait envisager de prendre le temps de revisiter périodiquement le cas d’affaires pour identifier les changements qui peuvent avoir un impact sur l’atteinte des bénéfices attendus.
Le chef de projet peut aider à faciliter des revues des bénéfices avec le propriétaire de produit en identifiant et en engageant les bonnes parties prenantes qui peuvent fournir un apport dans le processus d’évaluation. Si le chef de projet et le propriétaire de produit décident qu’il y a eu une réduction significative des bénéfices escomptés, ceci devrait déclencher une revue avec le l’entité de gouvernance appropriée pour se décider si le projet devrait continuer à être financé pour éviter d’y investir davantage à fonds perdus.
Les changements de périmètre fournissent une autre occasion pour les chefs de projet d’aller au-delà de leur rôle traditionnel de livraison de projet. Alors que comprendre les impacts sur le contenu, l’échéancier, les coûts et les contraintes secondaires de projet est important, les impacts sur la réalisation des bénéfices devraient aussi être identifiés pour éviter des conséquences inattendues.
L’adoption réussie de changement et leur suivi sont un autre apport critique dans la réalisation des bénéfices. Les meilleurs livrables de projet produiront une valeur minimale si le personnel opérationnel ne modifie pas ses comportements pour tirer le plein avantage des changements.
A travers ses interactions régulières avec les parties prenantes, le chef de projet est dans une position idéale pour recevoir un retour d’information des groupes impactés par les changements.
Le chef de projet peut supporter des propriétaires de changement dans l’analyse des parties prenantes et des plans d’action et peut assurer que la priorité est placée pour garantir que les agents de changement nécessaires sont inclus pour chaque domaine. Il peut passer en revue des plans de changement et aider à faciliter l’identification de risques et l’animation ses sessions d’évaluation requises pour comprendre quelles menaces peuvent exister qui entraveraient une adoption réussie.
Qu’on le veuille ou non, vous serez probablement évalués non seulement sur la livraison de projet, mais aussi sur si vos projets ont délivré les bénéfices attendus.
A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) est un guide professionnel sur le métier d’analyste d’affaires publié par l’International Institute of Business Analysis (IIBA®).
Le guide précise les compétences et les connaissances que devraient maîtriser les praticiens. Il s’agit d’un cadre de référence dans lequel sont décrits les domaines de connaissance, les activités et les tâches indispensables à une analyse d’affaire ainsi que les techniques associées.
Pour chacune de ces tâches sont décrits les connaissances de base, les compétences, les processus et les livrables dont l’analyste d’affaires a besoin pour être en mesure d’effectuer ces tâches avec compétence.
Plus toute une partie sur les techniques, méthodes et outils supportant ces domaines.
IIBA®, BABOK® Guide and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. CBAP® is a registered certification marks owned by International Institute of Business Analysis.
L’adaptation des entreprises à la business analyse n’est plus une nécessité mais une obligation. Avant 2020, l’entreprise doit (re)penser son modèle économique, ses modes de fonctionnement, sa création de valeur(s), ses modes de collaboration et ses ressources. Les outils en business analyse sont existantes mais les entreprises ignorent souvent l’usage qu’elles pourraient en faire.
Là n’est pas la question, il faut plutôt apporter à chacun les compétences nécessaires pour mettre en place une collaboration efficace entre toutes les parties prenantes internes et externes de l’entreprise.
Comprendre, analyser, synthétiser, expliquer, faciliter, explorer … naviguer dans la complexité seront les savoir-faire des nouveaux acteurs de cette transformation.
La Business Analysis (l’analyse d’entreprise) est la discipline qui regroupe l’ensemble de ces compétences. Celle-ci rassemble l’ensemble des métiers qui font la passerelle entre les nouvelles technologies et les attentes des métiers tout en s’assurant de la création de valeur(s).
Lors de cette conférence, notre objectif est de mieux comprendre l’intérêt de la business analyse et comment celle-ci peut devenir pour vous un avantage et non un désavantage ?
Des retours d’expériences, des conseils d’experts du domaine, des résultats significatifs seront là pour démontrer la pertinence du rôle de ces acteurs dans la réussite de ce nouveau challenge.
Si j’ai fait de l’Analyse métier au début de ma carrière (à l’époque nous utilisions MERISE !), que ce soit en ayant le titre de chef de projet ou consultant et si mon poste actuel au sein de HSBC Private Bank Swiss SA est « Senior Business Analyste », la plupart de ma carrière dans la banque privée suisse se déroule à des postes de Responsable de Programmes, Chef de Projets, Responsable de Département IT…
Et, enfin et surtout, en tant que Responsable Européen des Releases : je précise « surtout » car ce poste occupé pendant deux ans m’a permis de constater de nombreux errements quant à la gestion des exigences, qu’elles soient fonctionnelles ou non fonctionnelles. Et cela coûte cher et ajoute des risques quand nous devons « sortir à la dernière minute » des livrables non acceptables par le client car mal ou pas complètement analysés.
Tout le monde connait cette illustration sarcastique du produit livré ne correspondant ni aux attentes du client ni à la réalité de ces besoins. Mais c’est si vrai ! Ce serait une des raisons pour laquelle l’Analyse Métier s’est professionnalisée.
A ce propos, je me rappelle une anecdote de mon début de carrière, en 1988. Je travaillais sur la conception d’une nouvelle plateforme bancaire à Genève en utilisant MERISE au sein d’un gros projet : jeune analyste métier, je rédigeais des Spécifications Fonctionnelles Détaillées en étant contraint par les Spécifications Fonctionnelles Générales analysées précédemment par d’autres.
En discutant avec le métier je me suis aperçu que l’étape précédente avait été mal analysée et j’ai donc adapté mon analyse détaillée au besoin du métier. Je fus recadré par la Direction du Projet qui me demanda de respecter les contraintes de l’étape précédente même si cela allait à l’encontre de la satisfaction des besoins du métier ! Ma frustration est encore vivace !
Lors de ces deux années mon rôle fut de manager les livraisons coordonnées des différents projets livrés par les différents domaines du développement d’une banque privée genevoise dans un contexte européen.
Les livraisons étaient d’abord effectuées avec une fréquence trimestrielle, donc avec de nombreux livrables provenant de différentes équipes mais ayant des interdépendances.
Selon Carnegie, 25%-40% du budget des projets est utilisé par refaire à nouveau ce qui a déjà été fait … et que 70% – 85% de ces coûts de « re travail » sont dus à des erreurs dans la collecte des exigences métiers.Il est donc important que le Responsable de Programmes, Chef de Projets, comprenne et maîtrise ce domaine, même s’il est sous-traité à des équipes d’Analystes Métier, afin de diriger au mieux cette activité primordiale de la gestion de projet et d’en gérer les risques.
Travailler sur des supports de cours en anglais et donc progresser dans ce domaine,
Je vous donne rendez-vous dans quelques semaines une fois la certification passée pour vous faire part de la rétrospective de mon expérience !
un PMBoK de poche en français sur votre smartphone, liseuse ou tablette !
Stakeholder Engagement White Paper by Patrick Mayfield : Download
DantotsuPM.com 
