Créer votre équipe projet agile médicale !

 

Précédemment, je vous faisais part de ma méthode de gestion des projets médicaux de manière agile. Cette fois-ci je souhaite aller un peu plus loin sur le sujet en parlant des rôles et responsabilités dans ce type de projet. Je prendrai cette fois encore l’exemple d’un logiciel mais je montrerai comment transposer les rôles dans d’autres types de projets.

En effet, comme dans tout type de projet, il est vital de définir dès le début les rôles et responsabilités de chacun des acteurs du projet. En tant que coordinateur du projet c’est cet élément qui vous aidera pour avoir de la visibilité sur le projet. Cette visibilité vous permettra de savoir à tout moment la santé du projet et vous aidera à prendre des décisions.

Définir les rôles et responsabilités vous permettra également de faire gagner en autonomie votre équipe car chacun des membres du projet sera investi d’une mission à accomplir tout au long du projet.

Responsabiliser, c’est la clef. Mais comment s’y prendre ?

Dans un premier temps il s’agit de définir les différentes équipes qui interviennent au sein du projet. Dans un projet médical on peut distinguer les équipes de la manière suivante :

  • L’équipe Marketing : Chargée de collecter le besoin auprès des clients.
  • L’équipe Qualité : Chargée de veiller à ce que le produit respecte les procédures mises en place par l’entreprise.
  • L’équipe Réglementaire : Chargée de collecter les exigences permettant la mise sur le marché du produit
  • L’équipe Risques : Chargée d’identifier et de quantifier les risques du produit pour le patient
  • L’équipe Spécification : Chargée de transformer les besoins en exigences techniques
  • L’équipe Développement : Chargée de réaliser le produit
  • L’équipe Vérification : Chargée de tester les exigences techniques du produit
  • L’équipe Validation : Chargée de tester le produit auprès des utilisateurs finaux et clients.
  • L’équipe Support : Chargée de l’installation et de la maintenance du produit

Il s’agit ensuite de définir les différentes responsabilités de chaque équipe. Le plus concret est de définir pour chaque équipe un livrable clef. 

J’ai voulu présenter cela sous forme d’un tableau pour plus de simplicité : 

Equipe Rôle Livrable clef
Marketing Collecter le besoin auprès des clients. Scénarii d’utilisation du produit, appelé en agile “User stories”
Qualité Veiller à ce que le produit réponde au procédures mises en place par l’entreprise. Dossier de conception, appelé DHF pour Design History Files regroupant tous les documents rédigés et approuvés pendant le projet.
Réglementaire Collecter les exigences permettant la mise sur le marché du produit Document technique : resumé des caractéristiques du produit. Connu sous le nom de “Technical File”
Risques Identifier et quantifier les risques du produits pour le patient Dossier de management du risque : contient les risques tous évalués avec des mesures permettant d’atténuer l’occurrence et parfois la sévérité du risque.
Spécifications Transformer les besoins en exigences techniques Document de spécifications du produit, appelé Design Input, il regroupe toutes les exigences du produit définis à partir de tous les besoins des parties prenantes
Développement Réaliser le produit Le produit, par itérations successives.
Vérification Tester les exigences techniques du produit Le rapport de vérification contenant la liste des différents tests basés sur les exigences ainsi que leurs résultats
Validation Chargé de l’installation et de la maintenance du produit Le rapport de validation contenant la liste des différents tests réalisé auprès des utilisateurs finaux et leurs résultats
Support Chargé de l’installation et de la maintenance du produit Les procédures permettant l’installation et la maintenance du produit

En définissant les livrables on remarque assez facilement que sur chaque phase de projet il y a une équipe clef qui prend naturellement en main la phase de développement. En reprenant les phases d’un projet médical on peut mettre en face une équipe. Les phases sont détaillées dans mon précédent article :

Phase Equipe clef Livrable clef
Collecte du besoin client Marketing User Requirement Specifications
Ecriture des spécifications Spécifications Design Input
Développement Développement Le produit
Vérification Vérification Rapport de Vérification
Validation Validation Rapport de Validation
Transfert en production Support Procédures d’installation et de maintenance
La mise sur le marché Réglementaire Document technique

 

La qualité intervient dans toutes les phases du projet, en support.

Bien évidemment, ces phases ne sont pas uniques et se répètent avec plus ou moins d’intensité sur chaque « sprint » jusqu’à obtenir le produit final. Vous trouverez plus de détails en lisant mon précédent article.

 

Et les rôles agiles dans tout ça ?

 

Les deux profils clefs de la méthode scrum ont chacun leur équipe : Le Product Owner est dans l’équipe “Spécification”, à l’interface de toutes les équipes. Le Scrum Master fait partie de l’équipe “Développement” où il agit comme facilitateur.

Effectivement il s’agit également de mettre les différents profils dans chacune des équipes :

Equipe Rôle Profil
Marketing Collecter le besoin auprès des clients. Chef de produit : connaît le terrain, les praticiens et leurs besoins.
Qualité Veiller à ce que le produit réponde au procédures mises en place par l’entreprise. Chargé de projet Qualité Produit : connaît les procédures de l’entreprise et sait les faire respecter.
Réglementaire Collecter les exigences permettant la mise sur le marché du produit Chargé de projet Réglementaire : connaît le règlement des des dispositifs médicaux et les étapes permettant leur mise sur le marché.
Risques Identifier et quantifier les risques du produits pour le patient Chargé de projet Risque : expérience du terrain et des risques de manipulation qui peuvent exister.
Spécifications Transformer les besoins en exigences techniques Product Owner : lien entre les différentes équipes. Profil à la fois technique et connaisseur du terrain.
Développement Réaliser le produit

Scrum Master : coordinateur connaissant la méthode agile et qui veille au respect de l’application de la méthodes.

Architectes : connaissent les différents frameworks permettant de choisir ce qui correspond le mieux au besoin.

Développeurs : connaissent les langages utilisés et les frameworks.

Vérification Tester les exigences techniques du produit

Ingénieurs et techniciens vérification : savent rédiger des procédures de tests qui permettent de tester les exigences techniques.

Testeurs : savent appliquer une procédure de tests et également pousser le produit dans ses retranchements.

Validation Tester le produit auprès des clients.

Ingénieurs et techniciens validation : savent rédiger des procédures de tests qui permettent de collecter le retour des utilisateurs finaux.

Testeurs : ayant le profil des utilisateurs finaux. L’idéal étant directement des futurs utilisateurs.

Support Chargé de l’installation et de la maintenance du produit

Application specialist : connaît le client et sait réaliser des formations pour la prise en main du produit.

Integration specialist : connait le logiciel et sait le déployer dans différent environnement.

 

Définir les rôles, trouver les bons profils, c’est très bien mais la réussite dépend de comment vous allez les animer !

 

En tant que rugbyman, j’attache beaucoup d’importance à l’esprit d’équipe. Dans une équipe aussi diverse que peut être un groupe projet, il est très important de créer une cohésion d’équipe. Cela passe pour moi par des valeurs qui sont :

 

  • La transparence : L’ensemble de l’équipe connaît la décision et la direction du projet. Les choix sont justifiés.
  • La confiance : Chaque équipe est responsable et dispose de sa propre autonomie.
  • La co-construction : Toutes les équipes interagissent ensemble afin de trouver des solutions tout au long du projet. 

 

Ces valeurs ne sont bien sûr pas toujours partagées par l’ensemble des gens avec lesquels vous travaillerez. Néanmoins je pense qu’il est très important de les écrire en début de projet et de se les rappeler tout le long. Elles deviennent beaucoup plus évidentes dès lors qu’une cohésion se crée. Pour cela, je recommande fortement la mise en place de rituels qui ne sont pas proprement professionnels comme par exemple :

 

  • Une activité sportive : un tournoi de futsal par exemple
  • Des déjeuners d’équipe avec pour seule règle : ne pas discuter du projet
  • Des concours : création de memes, photos à thème avec un cadeau à la clef pour le gagnant

 

Néanmoins attention, ces rituels peuvent passer pour une tentative “d’acheter” les membres d’une équipe. Pour qu’ils ne passent pas comme tel il faut bien veiller à ce qu’ils puissent se faire sur le temps de travail et qu’ils commencent en tout début de projet.

 

Enfin, de manière plus classique il faut également veiller à ce que l’information circule bien sur l’ensemble des équipes et que chacun puisse remonter ses difficultés.

Pour cela il y a un rituel agile qui fonctionne bien : la mêlée quotidienne. Ses caractéristiques sont les suivantes :

  • Réunion debout
  • 15 min maximum
  • En début de journée

Elle permet à chacun de s’exprimer sur ce qu’il a fait hier et sur ce qu’il prévoit aujourd’hui. Il s’agit également d’une occasion de remonter les difficulté.

L’idéal est que chaque équipe puisse faire sa mêlée quotidienne et qu’une fois par semaine il y ait en plus un “maul”. Je pousse la métaphore rugbystique, malheureusement ce terme ne figure pas dans la méthode Scrum.

Un maul est pour moi une grande réunion debout où chaque équipe désigne un porte parole pour faire le bilan de sa semain et anticipe la semaine à venir.

 

Et si je ne fais pas un logiciel ?

 

Identifier les rôles et responsabilités peut se faire dans n’importe quel type de projet. Dans le cas d’un projet médical qui n’est pas un logiciel l’équipe support est bien plus large car elle comporte la production au sens large.

Dans d’autres domaines il y aussi certainement un peu moins de besoins sur les risques, la qualité et le réglementaire. Ces équipes peuvent potentiellement être regroupées en une seule équipe qui serait nommée qualité.

 

Qu’en pensez-vous ? Trouvez-vous nécessaire d’identifier les rôles et responsabilités en début de projet ? Comment faites-vous ?

 

Faites-moi part de vos commentaires sous cet article ou bien par email à mk@matthieukalita.com.

 

Suivez-moi sur les réseaux sociaux !