Un lancement de projet ludique et productif

Un de nos clients nous a demandé d’organiser le lancement d’un de ses projets stratégiques. Le projet n’est pas un mastodonte mais il est transverse et nécessite la concertation de 15 représentants utilisateurs de différents métiers (directeurs d’entité, comptables, contrôleurs de gestion, …). Ils viennent des 4 coins de la France sur 2 jours, avec des problématiques et des habitudes de travail différentes. Notre mission : optimiser leur temps de présence, converger vers une vision projet aboutie et concertée permettant au projet de se lancer.

Même si le groupe de pilotage a sa propre idée d’une solution logicielle commune, pas question de faire venir les utilisateurs sans leur donner la parole. Notre roadmap pour ces deux jours :

  • Poser la problématique et la vision générale du projet détenue par l’équipe de pilotage à qui la direction a accordé un budget.
  • Faire émerger les idées, partager les problématiques et les pratiques des futurs utilisateurs.
  • Identifier les pratiques communes, les solutions individuelles généralisables, les idées à explorer.
  • Créer une liste de besoins fonctionnels priorisables
  • Prioriser les besoins

Voici les activités mises en œuvre et leur résultat :

Jour 1

Présentation de la vision et des enjeux par l’équipe de pilotage.

« World Café »


Les « convives » se répartissent en 4 équipes de 4. Une première question est posée à tous, les groupes ont 20 minutes pour y répondre ensemble. Des post-it géants sont sur les tables pour consigner les idées qui émergent des discussions. À la fin du temps imparti, les convives se dispersent vers d’autres tables, seul « l’hôte » reste, et nous repartons pour 20 minutes. Hormis pour la première session, l’hôte commence par restituer ce qui a été dit à la session précédente.
L’objectif de cet atelier est double : que chacun ait conscience des contraintes des autres utilisateurs et qu’il puisse soumettre des idées à ses pairs et aux différents acteurs métier de l’organisation.

Deux questions sont posées pour focaliser les discussions :

  • Pour les 2 premières sessions de 20 minutes : « Qu’est-ce qui, dans l’organisation de mon travail au quotidien, pourrait améliorer la gestion de [la problématique métier du projet] ? »
  • Pour la dernière session de 20 minutes : « Comment l’outil informatique peut m’aider dans cette organisation ? »

L’ordre des questions incite à « oublier » l’outil pour se centrer sur le processus et les usages, d’autant qu’un outil historique est déjà en place. Le but est d’éviter les remontées du type « l’écran X est mal ordonnancé, il faudrait placer les boutons de validation en haut ». La réflexion sur le logiciel n’intervient qu’une fois les problèmes organisationnels traités.
Les discussions sont fournies et de haut niveau, la phase de restitution permet de dégager une première vision structurée des attentes des utilisateurs.

Cette activité n’est pas une collecte des besoins, mais un premier pas vers une vision partagée. Le résultat est conforme à cet objectif. De plus, il apparaît que le groupe est sur le bon axe de réflexion : on ne s’est pas attaché au fonctionnement mais aux attentes. La seconde journée sera tournée vers la formalisation des besoins et il faudra être vigilant sur l’exhaustivité de ceux-ci, tout en restant à un niveau macro.

Jour 2

Ce deuxième jour, il est important que la future Product Owner prenne la main sur l’animation fonctionnelle des ateliers (nous restons garant du « cadre » et veillons au bon déroulement des activités) afin qu’elle s’approprie les résultats et qu’elle soit clairement identifiée comme l’unique pilote du projet du point de vue des utilisateurs.

Personas


Les participants se répartissent en petits groupes métiers. On a préparé en amont les types d’ »usagers » à décrire (directeur de service, comptable, contrôleur de gestion, …) et nous décrivons pour l’exemple un premier persona ensemble sur le paper board. Indispensable pour bien comprendre la démarche !
5 personas ont été décrits dans les règles de l’art.

Récolte des besoins (Epics / User Stories)

Le travail se déroule avec les mêmes groupes, avec la consigne : « défendez les intérêts de vos personas ». Cet atelier demande une bonne présence du facilitateur pour répondre aux questions liées à la granularité et au placement dans les thèmes. Mais au bout de quelques US, les groupes deviennent autonomes.
La product Owner anime la restitution : description des US remontées, dédoublonnage.

Story map


Après avoir dessiné la story map sur un tableau blanc avec les 4 niveaux de priorisation MOSCOW (Must, Should, Could, Would/Won’t), la répartition des User Stories se fait en mode silencieux pour optimiser la durée de ce travail en groupe. Cette approche s’avère redoutablement efficace : après un premier tour avec le constat : « trop de must et should », le second tour a donné une carte bien équilibrée, le tout en 30 minutes.

Objectif atteint à la fin de cette deuxième journée. Tout le monde est satisfait du résultat. Reste une activité primordiale et très attendue : la roadmap du projet : que sera-t-on en mesure de traiter réellement ? Rendez-vous pris dès le lendemain matin avec la Product Owner et l’équipe technique pour répondre à cette question. On a assez de matière pour que ça aille vite, nous sommes confiants pour établir une première macro-planification en une matinée.

Jour 3 (matinée)

Planification

  1. La Product Owner affine la priorisation en affectant des valeurs aux User Stories dans chaque niveau de la Story Map.
  2. La Product Owner constitue un Backlog Produit en veillant à identifier des scénarii menant à des ensembles fonctionnels cohérents.
  3. L’équipe technique évalue la complexité relative des User Stories des niveaux « Must » et « Should ».
  4. L’équipe technique évalue sa vélocité prévisionnelle.
  5. La Product Owner répartit les User Stories dans les 7 sprints disponibles (nombre calculé selon la taille de l’équipe et le budget du projet).

On termine comme prévu à midi grâce au timeboxing et à l’efficacité des parties prenantes. Résultat : l’équipe technique peut traiter le « Must » et une partie du « Should ». Il faut le soumettre rapidement avec 3 options : ne pas lancer le projet (c’est beaucoup moins coûteux maintenant qu’en milieu ou (pire) en fin de projet), faire adhérer les utilisateurs à ce résultat, augmenter le budget alloué. C’est finalement la seconde option qui est retenue par le groupe pilote.

Voilà un projet agile qui démarre sur de bonnes bases : concertation, convergence, réalisme.

Les commentaires sont fermés.