Accueil bienveillant des changements dans les besoins exprimés

Le principe Agile d’accueillir des exigences changeantes avec bienveillance peut s’avérer le plus difficile à adopter !

Welcoming Changing Requirements

https://www.scrumalliance.org/community/articles/2017/may/welcoming-changing-requirements par Joseph Collins

Quelqu’un qui a passé du temps dans le cycle de vie de développement de logiciel traditionnel peut certifier que le principe Agile d’accueillir des exigences changeantes peut s’avérer le plus difficile pour des organisations basculant vers Agile. Dans le cycle de vie traditionnel, changer les besoins génère de la frustration, de la colère, du désespoir et, dans certains cas, des frais d’avocats et des coûts additionnels.

CertYou est partenaire de DantotsuPM

Le mouvement Agile demande que les clients et les organisations de développement travaillent ensemble et embrassent le changement pour le plus grand bénéfice de l’utilisateur final. Ce niveau de transparence exige que les murs tombent entre clients et développeurs. Il nécessite aussi que le client reconnaisse l’impact que le changement aura sur le projet et le coût complémentaire du changement sur le budget de projet, ainsi qu’acquérir un meilleur niveau de compréhension du travail.

Le client et les développeurs  atteignent une compréhension mutuelle

Dans une mauvaise mise en œuvre de Agile, les clients pensent qu’ils peuvent changer les exigences aussi souvent qu’ils le souhaitent et que le personnel de développement doit gérer ces changements. « Hé, vous avez dit que vous étiez Agiles, non ? »

Dans une bonne mise en œuvre, le client et le développement travaillent ensemble en étroite collaboration pour examiner et adapter le produit à chaque occasion possible. Comme le produit est revu fréquemment, le client et l’équipe maintiennent une compréhension partagée de l’état actuel du produit et de l’état actuel du marché. Quand le client change des exigences, le changement, son coût de mise en œuvre et son impact sur le projet dans son ensemble, sont mutuellement compris.

Jeff Sutherland utilise l’expression « Money for nothing and your change for free » (« l’Argent pour rien et votre changement gratuit ») quand il conseille des organisations sur la façon d’écrire des contrats Agiles (ndlt. Tiens, je ne savais pas que Jeff est fan de Dire Straits). En essence, on tient compte des deux côtés pour avoir une flexibilité maximale; l’équipe de développement tient compte d’exigences changeantes sans modifier le contrat ni charger des honoraires de modification et, en échange, le client consent à participer conjointement au processus Agile et au cycle de vie du développement de logiciel. Dans le cas où le client est satisfait avec moins de travail que prévu à l’origine, ils peuvent finir le contrat plus tôt, avec le paiement d’une partie prédéterminée du contrat restant.

Le changement est bon

La position est que le changement est bon. Il permet au client de satisfaire l’utilisateur final avec les fonctionnalités de plus forte valeur et de terminer le contrat au plus tôt. Il permet à l’entité de développement de recevoir la juste compensation pour livrer tôt et leur permet de se passer à l’opportunité suivante.

avec Ventura Asssociates, partenaire de DantotsuPM, recrutez les ressources critiques dont vous avez besoin pour vos projets

« Accueillir des changements dans les exigences, même tard dans le développement » ne signifie pas que le propriétaire de produit, le « Product Owner », est libre d’ajuster les critères d’acceptation après que le sprint ait commencé. Les processus Agiles qui exploitent le changement pour y gagner un avantage compétitif devraient être mis en œuvre avant l’exécution de sprint. De l’avis de tous, il existe un processus pour terminer un sprint plus tôt; cependant, c’est rare.

Les processus agiles facilitent l’élaboration progressive, la décomposition, le raffinement de l’arriéré de produit, une approche incrémentale et la planification de sprint; Ils exploitent pleinement le changement tout en protégeant l’équipe.

6 choses à faire au lancement du projet

Que faites-vous quand vous venez de prendre en charge un nouveau projet ?

Six things you should do when kicking off a project, http://www.susannemadsen.co.uk/blog/six-things-you-should-do-when-kicking-off-a-project, par Susanne Madsen

Commencez-vous immédiatement à planifier des tâches et mettre l’équipe en mouvement ?

Voici six choses que vous devriez vous efforcer de faire le plus tôt possible.

1. Validez le cas d’affaires

Comprenez et vérifiez le Business Case

Une des premières choses que vous devriez faire en tant que un chef de projet (PM) quand un nouveau projet vous est assigné est de découvrir pourquoi le projet est important et de valider qu’il a un bon cas d’affaires (« business case »). Comme PM vous n’êtes pas responsable du cas d’affaires, mais il est important que vous soyez familier avec son contenu et que vous y adhériez. Trop de projets sont commencés sans objectif, raisonnement ou bénéfice clairs et quand il se heurte plus tard à des problèmes, cela peut facilement se refléter négativement sur vous, le chef de projet. Ne laissez pas ceci se produire. Ayez une conversation avec les managers qui vous ont confié le projet et demandez-leur les raisons qui justifient le projet, à quoi ressemblera le succès une fois que le projet aura été achevé et comment voudraient-ils le mesurer. Comprendre pleinement le cas d’affaires vous rendra plus apte à prendre des décisions et diriger le projet dans la bonne direction.

2. Identifiez le comité de direction et le sponsor du projet

Identifiez précisément qui sont les décideurs

La chose suivante est de comprendre qui sont les décisionnaires sur le projet auxquels vous reportez. Idéalement il devrait y avoir une personne responsable – le sponsor – et qui accepte sa responsabilité. On me demande souvent si le PM et le sponsor peuvent être une même personne, et ce n’est pas un scénario idéal. Comme chef de projet, vous êtes responsable de livrer le projet selon les délais, coûts, qualité et bénéfices attendus par le sponsor. Si n’importe lequel de ces paramètres change, vous devez le remonter et chercher des conseils de la personne au-dessus de vous dans la hiérarchie du projet. Le sponsor aura normalement besoin de l’appui d’autres partenaires seniors dans l’organisation et ensemble ils forment le comité de direction. Assurez-vous que vous savez quels décideurs ont leur siège au comité de direction du projet et faites qu’ils se rencontrent sur une base régulière pour vous fournir des conseils managériaux et business sur votre projet.

3. Analyser les parties prenantes

listez et étudiez les parties prenantes

Il est très important que vous ne sautiez pas dans le projet et commenciez à planifier des tâches sans avoir une bonne compréhension de quelles sont les parties prenantes. Une partie prenante est une personne qui est impactée par le projet ou qui peut impacter le projet. Si vous n’identifiez pas toutes les parties prenantes au début, il y a un risque que des exigences fondamentales soient omises et que le projet ne puisse atteindre son but. Une autre raison pour laquelle vous devez prêter l’attention aux parties prenantes est que vous devez les gérer d’une telle façon qu’elles adhèrent au projet. Demandez-vous qui sont les influenceurs les plus importants et comment ils perçoivent le projet. Votre rôle est de garantir chaque personne adhère pleinement au projet en embarquant leurs réserves et en travaillant avec eux pour créer le meilleur résultat possible pour chacun.

4. Poser les règles du jeu

posez les règles de vie sur le projet

Sur de nombreux projets il n’est pas rare que les tâches ne soient pas toutes  achevées dans les délais souhaités et que le travail ne soit pas fait de la façon espérée par le chef de projet. Le problème fondamental est que le PM a souvent un jeu d’attentes qui n’ont jamais été explicitement exposées ou discutées. Celles-ci ne touchent pas seulement à la qualité du travail, mais aussi au comment il sera fait. Avoir un jeu de règles que personne n’a eu au départ et qui n’a même pas été énoncé est une recette pour le conflit. La meilleure façon de créer une équipe de projet efficace et harmonieuse est pour l’équipe de produire en commun un jeu de règles qui adressent comment ils travailleront ensemble. Ce n’est pas au PM de dicter ces règles, mais à  l’équipe principale (« core team ») de les définir. Une règle pourrait être que nous livrons toujours ce que nous promettons et que nous informons nos collègues dès que possible si nous ne sommes pas capables de tenir notre engagement. Une autre règle du jeu pourrait être que le PM tiendra toujours l’équipe informée de ce qui est décidé au niveau du comité de direction. Peu importent les règles tant qu’elles ont été collectivement consenties et fonctionnent pour chacun.

5. Recueillir les exigences

recueillez toutes les exigences

Il est probable que seules les exigences de haut niveau ou les objectifs ont été identifiés au moment où le projet vous est remis. C’est alors à vous et à l’équipe d’interviewer les parties prenantes pour découvrir dans le détail ce qu’elles exigent du projet. L’erreur que font beaucoup d’équipes consiste en ce qu’ils ne recueillent pas les exigences fondamentales suffisamment dans le détail et qu’ils ne sont pas explicites de ce qu’ils ne livreront pas. Cela peut aboutir à des malentendus, des désaccords et du travail à refaire. Alignez une série d’ateliers de recueil des exigences où vous décrivez l’état actuel et l’état futur souhaité et listez tous les changements qui seront nécessaires. Sur certains projets il n’est pas possible de définir toutes les exigences détaillées au départ car tout ne peut y être décidé à l’avance. Cependant, vous devez vraiment documenter toutes les fonctions fondamentales, mettre des priorités et comprendre à quoi ressemble un résultat réussi avant de commencer le travail. Créer des diagrammes de flux, des cas d’usage, des storyboards, des maquettes et des prototypes est une excellente façon de mettre en lumière les exigences plutôt que de les écrire dans un document textuel.

6. Créer le plan de haut niveau

visualisez les jalons de l’équipe vers le succès

Une autre activité qui doit être achevée avant que l’équipe ne s’engage sérieusement dans le travail est de créer collaborativement un planning des jalons marquants. Après avoir rassemblé la majorité des exigences vous êtes en bonne position pour identifier les 10-15 jalons les plus marquants et décider quand ils doivent être achevés. Il y a une énorme différence entre faire ce travail en isolation et engager l’équipe pour le réaliser ensemble. Quand vous engagez l’équipe et définissez le plan de haut niveau de manière collaborative, vous gagnez leur adhésion et d’une façon complètement différente. Après avoir identifié les événements marquants clefs, discutez de qui est responsable de chaque livrable et jalon et du plan détaillé qui va avec. Cette session de planification faite en collaboration devrait aussi comprendre une discussion sur les risques les plus importants, ce que vous allez faire pour les adresser et qui prend la propriété de chaque risque.

Méta Projets Management est partenaire de DantotsuPM

Quand vous prenez en charge un nouveau projet, ne commencez pas immédiatement à exécuter le travail. Vous devez d’abord au minimum comprendre si le projet a un cas d’affaires valable, qui sont le sponsor de projet et les parties prenantes, puis, aider l’équipe à définir un jeu commun de règles, recueillir toutes les exigences fondamentales et créer un plan à haut niveau des jalons majeurs auquel l’équipe toute entière adhère totalement.

comment BIEN réaliser la collecte et la compréhension des besoins des clients de vos projets ?

Savoir créer et entretenir un momentum semble être la clé pour éviter les échecs de projet.

Cependant, tout projet exige de bonnes définitions des besoins.

Comment les obtenir alors quand nous souffrons d’un excès massif d’informations ou au contraire d’un manque de données ?

Quand nous ne possédons pas les nécessaires compétences de facilitation pour les extraire?

Quand nous n’exerçons nos compétences d’analyse qu’occasionnellement ?

Voici ce que cette intéressante vidéo en anglais de Keith Ellis se propose d’aborder.

Méta Projets Management est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Enregistrer

12 Avril – Montréal – Atelier de spécialisation sur les scénarios utilisateurs

Le passage de l’idée au code se fait par l’entremise de scénarios utilisateurs (“user stories”) avec  Luc St-Laurent

Luc St Laurent

Comme ces scénarios deviennent le centre de la communication entre les utilisateurs et les développeurs, il est nécessaire de savoir les utiliser et de bien les écrire. L’atelier vise donc à aider les propriétaires de produits, les développeurs et les entraîneurs à mieux comprendre les scénarios usagers et, surtout, à les outiller afin d’améliorer la performance de leur scénarios.

Un événement organisé par Agile Montréal

CertYou est partenaire de DantotsuPM

Enregistrer

Enregistrer

Enregistrer

Pourquoi un Sprint Zéro avec Scrum et Agile ?

Le concept de Sprint Zéro est controversé !

Why Have Sprint Zero? par Sujatha Tokala

Sprint Zéro
Sprint Zéro

Je me rends compte que le concept de Sprint Zéro est controversé. Et dans mes premiers temps en Agile, j’ai été étonné par l’importance accordée à ce sujet. Je pensais que nous aurions des sessions de transfert de connaissances au fil du travail, alors, pourquoi avoir un sprint séparé ? Mais plus tard j’ai compris l’importance du Sprint Zéro dans l’organisation où je travaille. Je ne prétendrai pas que toutes les équipes en ont besoin, mais voici pourquoi c’est utile pour nous.

Les questions abordées au Sprint Zéro s’appliquent à la release toute entière.

Nous pourrions l’appeler Sprint Initial, Itération Zéro, ou Sprint de démarrage.

Selon mon expérience, le Sprint Zéro est limité dans le temps à seulement une semaine.

Notre équipe passe en revue l’ensemble des items de la release et quel travail devrait être achevé dans chaque sprint. En passant en revue chaque article de sprint, l’équipe identifie les endroits pour lesquels nous ne connaissons pas suffisamment bien les exigences qu’elles soient matérielles, d’architecture, logicielles, ou techniques.

Après que l’équipe ait revu les épics (ndlt. groupe de User Stories pour fournir une valeur métier) et fonctions priorisés de l’arriéré de produit, nous devons les annoter et préparer les sessions de revue avec le product owner, le propriétaire de produit. Nous devons comprendre l’environnement et le code exigé pour les items de l’arriéré de produit, indépendamment de si le code sera simple ou complexe.

Comment décomposer les niveaux d'exigence Agile (précédent billet à relire)
Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)

La raison principale d’introduire un Sprint Zéro est que nous ne voulons pas inutilement prolonger le temps nécessaire aux sessions de revue ou de transfert de connaissance depuis le Sprint 1 jusqu’à la fin. Donc, nous prenons une semaine pour préparer notre équipe avant de démarrer sur des arriérés de sprint.

Grâce à Agile, on nous donne l’opportunité d’en apprendre beaucoup en peu de temps.

L’équipe avancera de façon calme, sans pression excessive.

CertYou est partenaire de DantotsuPM
CertYou est partenaire de DantotsuPM

Utilisez-vous un sprint 0 en début de release sur votre projet Agile? Pourquoi? Quels en sont pour vous les bénéfices et inconvénients ?

Enregistrer

Enregistrer

Enregistrer

Enregistrer

comment découper vos « User Stories » #Agile (Histoires Utilisateur) avec la méthode INVEST

Splitting User Stories

http://www.agileadvice.com/2016/06/03/scrumxplean/splitting-user-stories/ par Faisal Ansari

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
Microsoft est partenaire de DantotsuPM

I.N.V.E.S.T.

  • IIndépendante
  • N– Négociable
  • V– de Valeur
  • EEstimable
  • SSuffisamment petite
  • TTestable

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:
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
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
    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
    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
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’optimise maintenant ‘ 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.

Autres Ressources Utiles

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

July 12 – Webinar (PMI®) – Rethink Requirements – The Natural Language Processing Approach

According to PMI’s Pulse of the Profession, “When projects do not meet their original goals and project objectives, inaccurate business analysis/requirements management is cited as the primary cause 47% of the time.”

And the increasing scale and complexity of projects is making it extremely difficult to assess and verify the project requirements. As a result – a huge amount of critical errors in project and systems development arise in the initial concept & design stages.

MPM est Partenaire de DantotsuPM
MPM est Partenaire de DantotsuPM

In this presentation and workshop, we will focus on how harnessing automated computational tools utilizing Natural Language Processing can help project managers ensure their requirements are consistently clear & are a joy to work with.

These project managers, business analysts, engineers and by extension their clients, will benefit in the earliest stages of a project to ensure poorly written requirements do not infiltrate later project stages leading to reduced stress, increased confidence and higher project success.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Registration

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

Enregistrer

June 7 – Webinar (PMI®) – Slashing Risks with User Experience Engineering (UX) Second Edition

Recent PMI Study calls Requirements Management a core competency for project and program success – and does so for a good reason.

User Experience47% of projects run into trouble due to incomplete or changing requirements & specifications, lack of user input or unrealistic expectations.

UX methods brought wild success to Apple, Google and other top players and it has been increasingly popular ever since.

But what most magazines don’t tell you is that it’s not just the Design part of UX that makes it so effective!

This is an expanded and updated version of popular session that ran on February 23, incorporating additional information based on your feedback.

Requirements Management is the single biggest risk for a majority of projects. According to PMI, 47% of initiatives that missed the mark did so because of requirements management. It’s truly is a core competency for project and program success.

Imagine your life without these risks. Little or no stakeholder management… Clarity around scope and direction… Stable, measurable requirements, completely aligned with business needs…

Design Thinking and UX brought wild success to Apple, Google and other top players and it has been increasingly popular ever since. But what most magazines don’t tell you is that it’s not just the Design part of UX that makes it so effective, it’s the new tools for Business Analysis.

Attend this webinar to learn about these extremely effective new Design Thinking tools and processes – for gaining accurate insights, discovering ‘missing’ requirements and hidden underlying problems.

Details and registration

Partenaire de DantotsuPM
Partenaire de DantotsuPM

Pourquoi je vais passer la certification PMI-PBA® ? Par Marc Burlereaux

Marc Burlereaux
Marc Burlereaux

Pourquoi le responsable de programme, chef de projet que je suis va passer une certification sur l’Analyse Métier et en l’occurrence PMI-PBA® : Professional in Business Analysis de PMI (Project Management Institute) ?

1. Mon parcours

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.

user requirementsTout 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.

C’est aussi une des raisons de l’émergence de l’agilité.

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 !

2. Mon expérience de Release Manager Européen

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

Nous avons travaillé avec les acteurs de la gestion du changement, à savoir le métier, les architectes, la sécurité, le test et la production afin que l’entrée en release soit validée par ces acteurs pour éviter de découvrir quelques semaines avant la livraison des dysfonctionnements tels que :
  • le périmètre de la livraison est bien déterminé : fonctionnellement mais aussi géographiquement. Cela semble couler de source, mais pour des projets de petite taille (moins de 200 jours homme), j’ai constaté un manque de rigueur fatal à toute mise en production.
  • les architectes ont bien validé la solution.
  • la sécurité a été impliquée et que ses recommandations ont bien été mises en œuvre.
  • le support et la production ait pu donner leurs exigences non fonctionnelles à respecter avant toute mise en place.
Mais cela ne nous a pas empêché d’avoir à gérer des « sorties de release » suite à des analyses métier déficientes avec diverses origines :
  • Difficultés de l’analyse métier « à distance » par nos équipes offshores
  • Oubli d’interdépendances fonctionnelles ou géographiques
  • Normes de sécurité non respectées
  • Rejet par des utilisateurs non préparés (en termes de ressources et de formation)
  • Manque de stratégie globale de test sur des livrables différents mais interdépendants

3. L’Analyse Métier réussie, facteur clé de la réussite des projets

Une des raisons majeures des échecs dans les projets est la mauvaise définition des besoins :
  • succès ou échecSelon 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.
  • Selon le Gartner, 60 à 80% des échecs de projets peuvent être directement attribué à une mauvaise analyse des besoins ou exigences.

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.

4. Pourquoi je vais passer cette certification PMI-PBA®

Tout d’abord pour les mêmes motivations qui m’ont fait passer d’autres certifications :
  • PMI PBATravailler sur des supports de cours en anglais et donc progresser dans ce domaine,
  • Réfléchir sur des concepts et outils que j’utilise au quotidien mais dont je peux utiliser l’amélioration,
  • Acquérir de nouveaux outils,
  • Rencontrer des personnes ayant les mêmes centre d’intérêts toutefois dans des domaines différents afin d’enrichir ma créativité.
Mais aussi :
  • Assurer une meilleure initiation des projets / programmes
  • Éviter d’avoir à retravailler des livrables du projet
  • Savoir déjouer les pièges de l’Analyse Métier à distance lorsqu’elle est déléguée à des partenaires éloignés comme en Inde, Chine ou Pologne, mais aussi quand une équipe centrale collecte des besoins pour différentes entités locales. Mon expérience m’a montré que les « Analyses Métier à distance » sont pleines de pièges à déjouer : autant anticiper !
  • Posséder une double compétence de plus en plus prisée pour des projets petits à moyens ou la réduction des coûts implique de savoir tout faire
  • S’assurer dès le début du projet que la collecte des exigences métier est intégrée dans un mécanisme de documentation des tests d’acceptation
  • Pour introduire de l’agilité, car le client a désormais le droit de changer d’avis … mais aussi car l’environnement incertain et instable requiert cette flexibilité accrue
Détails sur la certification PMI-PBA du PMI
Détails sur la certification PMI-PBA du PMI

Et enfin parce que l’analyse métier réussie est un facteur clé de succès du projet !

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 !

Partenaire de DantotsuPM
Partenaire de DantotsuPM

22 Mars – Montréal – Gestion de requis des clients dans le développement d’un nouvel avion

Un nouvel événement du PMI Montréal avec André Blanchet, plus de 25 ans d’expérience dans l’industrie aéronautique.

airbus en constructionOutre des compagnies telles Boeing, Airbus, Bombardier et Embraer, peu de compagnies sont capables d’entreprendre le développement d’un nouvel avion.

C’est une industrie caractérisée par la sécurité du produit où des requis de certification sévères exigent des fabricants des processus d’ingénierie, de qualité et de production approuvés depuis fort longtemps, par les autorités aéronautiques. Le développement d’un nouvel avion prend plusieurs années et requiert des efforts de gestion de projet qui sont contraints par des processus existants. Les requis des clients qui sont établis au début du programme sont souvent remis en question par les acheteurs et par des changements de conditions de marché.

Campana & Schott est partenaire de DantotsuPM
Campana & Schott est partenaire de DantotsuPM

Dans cette conférence, André Blanchet explique les enjeux de la gestion de requis des clients vis-à-vis la gestion de projet d’un nouvel avion.

MPM est Partenaire de DantotsuPM
MPM est Partenaire de DantotsuPM