Vous avez besoin d'aide? +41 43 588 10 36
Choisissez votre pays et votre langue
Vous avez besoin d'aide? +41 43 588 10 36
Choisissez votre pays et votre langue
Home/Actualité
Actualité

Actualité

Découvrir les dernières nouvelles du monde de la gestion de projet et de l’IT.

Date: 16/06/2021
Dans un monde où les modes de travail évoluent constamment, les méthodologies de gestion de projet des organisations doivent également être révolutionnées. La gestion de projet est devenue l’un des piliers les plus importants au sein de toute entreprise car elle a été reconnue comme l’un des facteurs fondamentaux de son bon fonctionnement. Les entreprises recherchent des technologies, des systèmes et des processus qui les aident à personnaliser et à optimiser la gestion de projet. Les clients connaissent une croissance exponentielle et, d’une manière ou d’une autre, les entreprises doivent être capables de s’adapter. Les méthodes Agiles sont nées pour apporter cette flexibilité manquante, dans le monde de la gestion de projet, en se détachant complètement des méthodes traditionnelles, également appelées waterfall, en cascade ou cycle en V. Nous analyserons dans cet article les avantages et les inconvénients des méthodes agiles et traditionnelles.  

Méthode traditionnelle, waterfall, en cascade ou en cycle v

L’approche en cascade est une décomposition des activités du projet en phases séquentielles linéaires, où chaque phase dépend des livrables de la précédente et correspond à une spécialisation des tâches. Le modèle en cascade est né dans les secteurs de la fabrication et de la construction, où les environnements physiques hautement structurés signifiaient que les modifications de conception devenaient prohibitives beaucoup plus tôt dans le processus de développement. Lorsqu’il a été adopté pour la première fois pour le développement de logiciels, il n’existait aucune alternative reconnue pour le travail créatif basé sur la connaissance.  

Cycle en V : avantages et inconvénients

Avantages

Inconvénients

Cadre défini Tout le monde a une compréhension claire du calendrier et des livrables du projet avant le début du projet. Le périmètre du projet est convenu à l’avance par l’équipe de développement et leurs clients.L’implication du client est moindre Une approche sans intervention ne convient pas à tous les types de produits. Certains clients voudront être impliqués au fur et à mesure que le projet avance. S’il n’y a pas de cadre pour cette implication, l’approche en cascade pourrait conduire à la frustration des deux côtés.
Documentation Chaque phase du processus est documentée en détail pour éliminer tout malentendu ou raccourci.Les changements peuvent être difficiles Tout l’intérêt de la méthodologie en cascade est qu’elle suit des étapes claires et un calendrier défini. Une fois ces éléments en place, il peut être difficile d’apporter des modifications une fois que l’équipe de développement rencontre un obstacle. L’adaptabilité est un élément crucial à prendre en compte pour le développement logiciel, d’autant plus qu’il peut être difficile pour les clients d’avoir une compréhension complète du projet avant qu’il ne commence.
Approche sans intervention Le travail en cycle en v permet une approche sans intervention de la part du client. Une fois la conception initiale et le plan de projet en place, la présence continue du client est peu nécessaire jusqu’à la phase d’examen.Les exigences manquent d’efficacité un domaine qui fait presque toujours défaut est l’efficacité des exigences. Les clients sont parfois intimidés par les détails, et des détails spécifiques, fournis en début du projet, sont requis avec cette approche. De plus, les clients ne sont pas toujours en mesure de visualiser une application à partir d’un document d’exigences.
 

Méthode Agile

La principale différence entre une approche agile ou en cascade pourrait être résumée en disant que l’approche en cascade valorise la planification à l’avance, tandis que l’approche agile valorise l’adaptabilité et l’implication des clients. La méthodologie agile comporte deux éléments principaux : le travail d’équipe et le timing. Au lieu de créer un calendrier pour un grand projet de développement logiciel, Agile divise le projet en éléments livrables individuels. Ces phases « timebox » sont appelées « sprints » et ne durent que quelques semaines. Une fois chaque sprint terminé, les feedbacks de la phase précédente sont utilisés pour planifier la suivante.  

Agile : avantages et inconvénients

Avantages

Inconvénients

Implication du client En permettant au client de déterminer la priorité des fonctionnalités, l’équipe comprend ce qui est le plus important pour l’entreprise du client et peut fournir les fonctionnalités qui offrent le plus de valeur commerciale. Le client acquiert un fort sentiment d’appartenance en travaillant étroitement et directement avec l’équipe de projet tout au long du projet.Disponibilité du client Le très haut degré d’implication du client, bien qu’important pour le projet, peut présenter des problèmes pour certains clients qui n’ont tout simplement pas le temps ou l’intérêt pour ce type de participation.
Livraison anticipée et prévisible En utilisant des sprints à calendrier fixe et à horaire fixe de 1 à 4 semaines, les nouvelles fonctionnalités sont livrées rapidement et fréquemment, avec un niveau élevé de prévisibilité. Le développement agile est souvent plus axé sur l’utilisateur, notamment en raison de directives plus fréquentes et plus fréquentes du client.Forte implication requise Agile fonctionne mieux lorsque les membres de l’équipe de développement sont entièrement dédiés au projet. Étant donné qu’Agile se concentre sur la livraison dans des délais impartis et la redéfinition fréquente des priorités, il est possible que certains éléments définis pour la livraison ne soient pas terminés dans le délai imparti. Des sprints supplémentaires (au-delà de ceux initialement prévus) peuvent être nécessaires, augmentant le coût du projet. De plus, l’implication du client conduit souvent à des fonctionnalités supplémentaires demandées tout au long du projet. Encore une fois, cela peut augmenter le temps global et le coût de la mise en œuvre.
Simplification des changements Alors que l’équipe doit rester concentrée sur la livraison d’un sous-ensemble convenu des fonctionnalités du produit au cours de chaque itération, il est possible d’affiner et de redéfinir en permanence le backlog global du produit. Des éléments de backlog, nouveaux ou modifiés, peuvent être planifiés pour la prochaine itération, offrant la possibilité d’introduire des changements en quelques semaines.Refactoring fréquent La nature itérative du développement Agile peut conduire à une refactorisation fréquente si l’intégralité du système n’est pas prise en compte dans l’architecture et la conception initiales. Sans cette refactorisation, le système peut souffrir d’une réduction de la qualité globale. Cela devient plus prononcé dans les implémentations à plus grande échelle, ou avec des systèmes qui incluent un haut niveau d’intégration.
 

Différences entre les approches Agile ou traditionnelles

Méthode Agile

 Méthode traditionnelles

Toute approche Agile organise le cycle de vie du développement du projet en sprints et suit une approche incrémentale.Le processus de développement du projet est divisé en phases/séquences distinctes.
La méthodologie Agile est connue pour sa flexibilité.La méthode traditionnelle ou en cascade est un processus de conception séquentielle.
Agile peut être considéré comme une collection de nombreux projets différents.Le cycle en V est une méthodologie de développement structurée, donc la plupart du temps, elle peut être assez rigide.
Agile est une méthode assez flexible qui permet d’apporter des modifications aux exigences de développement du projet même si la planification initiale est terminée.Le développement du projet sera réalisé en une seule pièce.
La méthodologie Agile suit une approche itérative en raison de sa méthode de planification, de développement ou encore de la répétitivité des autres phases, qui peuvent apparaître plus d’une fois.Il n’est pas prévu de modifier les exigences une fois que le développement du projet commence.
Le plan de test est revu après chaque sprint.Toutes les phases de développement du projet telles que la conception, le développement, les tests, etc. sont réalisées une seule fois dans le modèle Waterfall.
La méthodologie agile est un processus dans lequel les exigences sont censées changer et évoluer.Le plan de test est rarement discuté pendant la phase de test.
Dans la méthodologie Agile, les tests sont effectués simultanément.La méthode est idéale pour les projets qui ont des exigences précises et aucun changement attendu.
Agile introduit une mentalité de produit où le produit répond aux besoins des clients finaux et se modifie selon les demandes du client.Dans cette méthodologie, la phase « Test » vient après la phase de conception.
La méthodologie Agile fonctionne exceptionnellement bien avec le temps et les matériaux ou un financement non fixe. Cela peut augmenter le stress dans les scénarios à prix fixe.Ce modèle montre une mentalité de projet et se concentre entièrement sur la réalisation du projet.
Agile favorise le travail des petites équipes mais dévouées et avec un degré élevé de coordination et de synchronisation.La coordination/synchronisation des équipes est très limitée.
Le Product Owner, avec son équipe, prépare les exigences tous les jours durant un projet.Le business case prépare les exigences avant le début du projet.
L’équipe de test peut participer au changement des exigences sans problème.Il est difficile pour le test d’initier un quelconque changement dans les exigences.
La description des détails du projet peut être modifiée à tout moment au cours du processus.Une description détaillée a besoin d’une approche de développement en cascade.
Les membres de l’équipe Agile sont interchangeables, par conséquent, ils travaillent plus rapidement. Il n’y a pas non plus besoin de chefs de projet car les projets sont gérés par toute l’équipe.Dans la méthode en cascade, le processus est toujours simple, le chef de projet joue donc un rôle essentiel à chaque étape.
  La méthodologie de développement que vous utilisez dépend de plusieurs facteurs clés. Contactez-nous et nous vous aiderons à découvrir quelle méthodologie est la mieux adaptée à vos besoins !  
Lire plus
Date: 09/06/2021
On entend souvent parler de la problématique de “recrutement des talents” dans le secteur informatique mais en réalité la problématique est bien trop restrictive puisqu’elle s’étend en réalité à l’entière gestion des talents. En effet, le recrutement est une activité technique qui ne représente qu’une partie minime de la problématique globale et s’inscrit dans un cadre beaucoup plus large. Dans une entreprise, il faut avoir une vision holistique (principe directeur d’ITIL 4). En effet, les personnes représentent l’actif le plus important d’une entreprise, le côté humain est primordial dans la course au succès. Le cadre de référence ITIL 4 ne parle d’ailleurs pas que de talent mais bien de “workforce”. En tant que manager IT ou ressources humaines ont doit penser aux équipes mais aussi aux talents qu’il y a dans les équipes. Les deux sont liées mais nous traiterons uniquement la gestion des talents dans cet article.  

Gestion des talents

La gestion des talents n’est plus de la responsabilité unique des Ressources Humaines comme c’était le cas auparavant. Elle doit désormais être au cœur des préoccupations de tout le management (des directeurs IT et métier, au team leader), tous ces managers quelque soit leur séniorité doivent penser gestion des talents. Dans le monde dans lequel on vit, qui est en mouvement constant, et évolue très vite, la gestion des talents n’est pas quelque chose de statique que l’on revoit tous les 3 à 5 ans mais quelque chose qui bouge en permanence. Il faut y consacrer du temps et ce constamment. Autrefois le recrutement était une tâche purement administrative où les Ressources Humaines publiaient un article dans un journal. De nos jours, les RH effectuent une publication sur linkedin, un site web ou une plateforme et si on veut être efficace et efficient il est inévitable que l’activité RH deviennent partie intégrante des activités stratégiques, tactiques, opérationnelles et administratives. Dans la formation ITIL Drive Stakeholder Value, on parle de “triple bottom line”. Avant la “bottom line” était exclusivement financière mais elle s’est élevée au fil du temps pour devenir triple : ainsi elle comprend désormais le côté financier, environnemental et social.  

Le modèle 7S de McKinsey

Au niveau stratégique, la gestion des talents (le social) doit faire partie intégrante de la stratégie globale d’entreprise et donc de la stratégie de la direction informatique. On retrouve la composante “social” dans le modèle de Mc Kinsey en 7 S. En effet, pour qu’une organisation soit performante, l’ensemble de ses composantes doivent être alignées et évoluer dans le même sens pour des objectifs communs. Mc Kinsey modele 7S Le modèle 7S de McKinsey, repris dans la formation DevOps Leader et la formation Lean, offre une méthodologie pour réaliser cette mise en cohérence. Le modèle met en relief les sept domaines de performance internes aux entreprises devant être alignés. Interdépendants, ils se renforcent mutuellement. Ces 7 points comprennent bien entendu la gestion des talents (staff & skills), qui reprend le côté humain de ce modèle. De même, dans la gestion des talents on retrouve un autre modèle en 7 étapes : l’expérience employée (customer and user journeys). modele-7S-de-McKinsey-customer-journey
  1. Explorer : comprendre le marché et connaître les différentes parties prenantes
  2. Engager/s’impliquer : favoriser les relations et se sentir concerné.
  3. Offrir : rédiger et proposer des offres d’emplois
  4. Se mettre d’accord : aligner les attentes et convenir du recrutement
  5. Intégrer : accueillir et intégrer les nouvelles ressources
  6. Co-créer : le collaborateur travaille
  7. Réaliser : réaliser de la valeur et s’améliorer
Ce modèle fonctionne aussi bien pour choisir un nouveau fournisseur qu’un nouveau collaborateur. Le recrutement en soi reprend les étapes 3 “Offer” et 4 “Agree” du processus alors que la gestion des talents est beaucoup plus large. Elle comprend toutes les étapes de l’étape 1, en amont, “Explore” à l’étape 7, en aval, “Realize” (bilans annuels,..) . Les soft skills (les compétences humaines) s’intègrent dans ce qu’il s’appelle les formes “shapes”. Au niveau des formes, il y a 10 ou 20 ans, on recherchait des professionnels en I, avec des profils purement techniques et une mono spécialisation. Le “I” représente la profondeur technique, la compétence du recruté. (ex : expert oracle, expert windows,…).  

E-shape profiles

Des années plus tard, les professionnels se sont aperçu que cela n’était pas suffisant et ont commencé à rechercher des professionnels ayant également une vision et une connaissance humaine, de l’entreprise et de la direction informatique . Le I s’est transformé en T. Human shape Les entreprises se sont mises à chercher des professionnels ayant une connaissance technique verticale,  une connaissance de l’IT, une connaissance des métiers de l’entreprise mais également des connaissances générales. Dans le monde du cloud notamment on s’aperçoit que la mono compétence profonde n’est plus suffisante. Lors des recrutements, les profils recherchés auront donc deux compétences techniques. On les appelle les profils Pi-shaped (π). Dans un monde où tout le monde a un accès aux outils open-source, cela n’est pas encore suffisant. Il est préférable d’être expert dans tous ces outils ainsi que de leur langage de programmation. (java, C, C++, python,..). On demande lors du recrutement de connaître deux, trois voir quatre langages. On obtient donc des profils qui ont la forme du peigne ou “comb” en anglais. Les dents du peigne correspondent aux profondeurs technologiques du futur recruté. L’évolution du recrutement est passée d’une barre verticale à N barres verticales auquel s’ajoute une barre horizontale les soft skills (savoir communiquer, être persuasif, être un leader, un décideur, faire confiance, savoir déléguer, gérer des conflits, être autonome dans la gestion de son temps (le self management dans SCRUM). Les soft skills tournent autour de la culture que l’on rencontre dans tous les référentiels.  

La gestion des talents est devenue une pratique au sens ITIL 4

Pour se faire, la gestion des talents est devenue une pratique au sens ITIL 4  du terme. En tant que pratique pour atteindre les objectifs d’une gestion efficiente on aura 3 objectifs :
  • L’alignement avec la stratégie métier (recrutement en phase à la stratégie métier).
  • La contribution à la réalisation des objectifs (bon talent pour réussir les objectifs).
  • L’aspect administratif du recrutement supporte la stratégie et les objectifs.
Pour réussir ces 3 objectifs on retrouve 4 grands axes :
  • la gestion de l’expérience de l’employé (on ne fait pas que le recruter).
  • la formation et le développement continus (recrutement sur un profil suivi d’une montée en compétence continue).
  • le leadership conscient (manager et leader, coach).
  • la culture doit être saine et entretenue.
Les leaders doivent être les évangélisateurs de la culture d’entreprise au niveau de ses valeurs. Comme toute pratique, en plus d’avoir des objectifs, il faut savoir les mesurer. Pour cela 2 KPI :
  • le pourcentage d’initiative stratégique que l’organisation aura raté par manque de bons talents au sein de l’équipe.
  • le niveau de satisfaction des employés, qui sera mesuré en prenant en compte les efforts continus à partir du recrutement pour que la personne se sente toujours bien dans l’entreprise.
Pour finir, les 6 activités de la gestion des talents sont alignées sur les 7 activités citées dans DSV :
  • définir la vision des compétences : qu’est-ce qu’on devrait avoir comme compétences dans la DSI/dans l’entreprise.
  • faire un état des lieux, une évaluation des compétences actuelles.
  • faire un plan de développement et d’optimisation des talents.
  • suivre les plans de développement.
  • gérer les exceptions (on manque de talent, on va embaucher).
  • revoir complètement ce qui vient d’être dit au niveau des activités.
Ces activités s’inscrivent dans la mouvance de la roue de Deming. Pour rappel, la méthode comporte quatre étapes, chacune entraînant l’autre, et vise à établir un cercle vertueux. Sa mise en place doit permettre d’améliorer sans cesse la qualité d’un produit, d’une œuvre, d’un service, etc.
  • Plan : préparer, planifier (ce que l’on va réaliser) ;
  • Do : développer, réaliser, mettre en œuvre (le plus souvent, on commence par une phase de test) ;
  • Check : contrôler, vérifier ;
  • Act : (ou Adjust): agir, ajuster, réagir
Lire plus
Date: 03/06/2021
MSP est l’acronyme de Managing Successful Programmes, à ne pas confondre avec Managed Service Provider. MSP est la méthode de gestion de programme la plus connue à ce jour.  Le guide MSP aide les organisations à relever les défis courants, liés à la réalisation de changements transformationnels.  

MSP pour la gestion de programme

Les compétences en gestion de programme deviennent de plus en plus importantes car elles aident les organisations à faire face au changement. S’attaquer à la transformation avec un leadership efficace et un contrôle stratégique aide les organisations à faire face avec succès aux changements constants. MSP a été utilisé par diverses organisations à travers le monde et convient à une grande variété de programmes, de situations et d’environnements de travail. MSP est adaptable, complet et applicable. MSP fournit un cadre structuré pour la gestion des programmes et aide les organisations à diviser les programmes en projets individuels, chacun clairement défini.  

5 avantages à adopter MSP

MSP fournit une base pour la gestion des programmes et la réalisation de bénéfices mesurables grâce au changement. MSP accompagne les organisations et les professionnels dans la gestion efficace des projets et programmes. Les principaux avantages de la mise en œuvre du cadre sont :
  1. MSP allie normes et rigueur à la flexibilité pour répondre à des situations spécifiques.
  2. MSP fournit une approche pratique, étape par étape, pour une conception et une gestion réussies de programmes.
  3. MSP englobe les principes clés, les questions de gouvernance et les processus nécessaires pour amener le changement.
  4. MSP indique comment utiliser, intégrer et appliquer MSP pour obtenir des résultats de haute qualité.
  5. MSP comprend des exemples concrets de la façon d’appliquer la gestion de programme.
 

Éléments clés de MSP

MSP est composé de trois éléments :
  • 7 principes universels.
  • 7 thèmes facilitant la gouvernance et les contrôles essentiels.
  • 7 processus représentant le cycle de vie incrémental qui, s’il est flexible et adaptable, permet une progression cyclique ordonnée avec des critères de décision clairs.

Les principes MSP 

Les principes MSP découlent des leçons positives et négatives tirées de différentes expériences de programme. Ce sont des facteurs communs qui assurent le succès d’un changement transformateur. Les 7 principes MSP sont :
  1. Rester aligné avec la stratégie de l’entreprise Ce principe signifie qu’à aucun moment le programme ne doit s’écarter des objectifs stratégiques de l’organisation.
  2. Piloter les changements Ce principe met l’accent sur l’importance de conduire efficacement le changement.
  3. Imaginer et communiquer un avenir meilleur Ce principe garantit que toutes les parties prenantes et les ressources impliquées dans le projet sont alignées.
  4. Se focaliser sur les bénéfices et les menaces associées  Ce principe garantit que tous les bénéfices sont réalisés et que tous les risques sont gérés.
  5. Ajouter de la valeur Ce principe vérifie que le programme crée de la valeur pour l’organisation.
  6. Concevoir et livrer une capacité cohérente  Ce principe assure la livraison des aptitudes / compétences utiles et conformes aux objectifs du programme.
  7. Tirer des leçons de l’expérience  Ce principe vise à éviter de répéter des erreurs qui pourraient compromettre la réussite du programme.

Les thèmes de gouvernance MSP 

Les thèmes de gouvernance MSP définissent l’approche d’une organisation en matière de gestion de programme. Ils permettent à l’organisation d’établir le bon leadership, l’équipe de livraison, la structure et le contrôle, pour assurer les meilleures chances de succès.

Le flux transformationnel MSP (transformational flow)

Le flux transformationnel MSP fournit un chemin tout au long du cycle de vie du programme, de sa conception à la réalisation des résultats et des bénéfices. MSP-flux-transformationnel

Les rôles clés MSP

MSP définit les rôles et les responsabilités de tous ceux qui font partie de la direction d’un programme. Pour avoir un leadership efficace, une prise de décision éclairée et un système de gestion flexible sont nécessaires. Les principaux rôles impliqués sont :
  • Les sponsors.
  • Le directeur exécutif de programme.
  • Le responsable de programme.
  • Le responsable de la conduite du changement.
  • Le bureau de programme.
 

MSP 4 vs MSP 5

Axelos a récemment publié la 5e édition du guide MSP, qui n’avait pas été mis à jour depuis 2011. Cette nouvelle édition répond donc à un certain nombre de changements intervenus dans le monde de la gestion de programmes et de projets depuis. Pour en savoir plus sur la nouvelle version, consultez notre article Lancement du guide MSP 5è Édition.  

La certification MSP

Le schéma de certification MSP comprend deux niveaux :
  • MSP Foundation.
  • MSP Practitioner.

MSP Foundation 

La partie théorique de la méthode MSP. L’examen MSP Foundation confirme que vous avez les connaissances nécessaires pour travailler avec ou en tant que membre d’une équipe de gestion de programme qui utilise MSP.

MSP Practitioner

Ce niveau fournit les connaissances nécessaires pour appliquer et adapter le guide MSP à des programmes réels. L’examen MSP Practitioner vise à confirmer que vous avez une compréhension suffisante de la façon d’appliquer le guide dans différents environnements et scénarios.  

Suivre une formation MSP

Vous souhaitez découvrir le guide MSP ? QRP International est un ATO (Accredited Training Organizations) reconnu pour donner des formations MSP et accrédité par PeopleCert au nom d’Axelos. Contactez nous maintenant Source: Axelos
Lire plus
Date: 14/06/2021
«Est-il possible d'apprendre à mieux gérer le changement dans un monde agile ?». Tel était le challenge que Melanie Franklin, experte renommée Agile & Change Management, s’est lancé il y a quelque temps. Pour répondre à cette problématique, elle publie en 2014 le livre "Agile Change Management - a practice framework for successful change planning and implementation". Le manuel fournit une approche pour gérer les initiatives de changement transformationnel, en utilisant un grand nombre d'idées issues des méthodologies agiles. Ce livre a débouché sur la création de la certification Agile Change Management. Il y a deux ans, nous avons eu l'occasion d'interviewer Melanie Franklin et aujourd'hui nous sommes fiers d'annoncer le lancement de la formation Agile Change Agent.  

Agile Change Agent : Guide pour la conduite de changement agile

Une approche agile du changement consiste à réaliser des changements par vagues de changements. Selon Melanie Franklin, Agile Change Management consiste à accepter que dans ce monde de changements très rapides, planifier chaque détail de changement à l'avance n'est pas une bonne idée. La formation et la certification Agile Change Agent fournissent aux participants des directives pour mener à bien un changement. La formation donne un aperçu de la façon de planifier et de gérer toutes les activités nécessaires pour concevoir, fournir et adopter le changement de manière agile. La formation répond aux questions «Qu'est-ce qui fait qu’un changement est réussi ?» «Que devons-nous vraiment savoir pour réussir un changement ?» «Comment gérer nos changements dans un monde agile ?». Il ne s'agit pas de ce que vous devez faire mais de la manière dont vous êtes censé le faire et des techniques que vous pouvez utiliser.  

Êtes-vous fait pour devenir Agile Change Agent ?

Le rôle Agile Change Agent concerne toutes les personnes responsables de la création de nouvelles façons de travailler à la suite d'un investissement dans un projet, les personnes qui jouent un rôle dans la conduite du changement, ou encore celles en charge d’identifier les changements et l’impact de ces changements sur les personnes et leur travail au quotidien et à long terme. Vous êtes également concerné si vous êtes impacté par des changements dans les départements des ventes, du marketing, des ressources humaines, des finances ou d'autres services. Vous avez des priorités quotidiennes, vous utilisez les méthodes de travail existantes pour satisfaire la demande actuelle des clients et faire le travail, mais vous mobilisez également vos collègues et vous-même pour participer aux changements que votre organisation opère / décide. Vous agissez donc comme un Agile Change Agent. Comprendre les activités pour une gestion efficace du changement et les inclure dans votre plan de projet Agile augmente les chances que les livrables de votre projet soient adoptées en tant que nouvelles habitudes de travail. Les individus n’ont peut-être pas le titre d’Agile Change Agent, mais le fait est qu'en plus de leur travail quotidien, ils jouent un rôle pour aider à faire changer les choses et finalement intégrer le changement dans les méthodes de travail actuelles.  

Pourquoi suivre la formation Agile Change Agent ?

  • La conduite du changement agile est expliquée d’un point de vue pratique et pas seulement théorique.
  • La formation contient de nombreuses techniques de résolution de problèmes, très utiles au quotidien.
  • Vous recevrez un kit pratique de techniques, de listes de contrôle et d'outils pour commencer à gérer vos projets de changement, une fois de retour dans votre environnement professionnel.
  • La formation aide ceux qui ont des connaissances sur la conduite du changement à comprendre l’approche Agile, et ceux qui connaissent Agile à en apprendre davantage sur la conduite du changement.
  • La certification Agile Change Agent est incluse et vous permet d’enrichir votre CV. La certification démontre à vos (futurs) clients ou employeurs vos compétences en Agilité et en conduite du changement - deux sujets d’actualité !
  Vous souhaitez en savoir davantage sur la certification Agile Change Agent ? Notre équipe se tient à votre disposition.
Lire plus
Date: 26/05/2021
Les hôpitaux traversent une période de changement et de réforme. Ils sont confrontés à la tâche difficile de réaliser la transformation digitale tout en protégeant la sécurité des patients, la qualité du service, l’utilisation efficace des ressources et la productivité continue. Ce changement n’est pas dû à la situation actuelle liée Covid-19. Le secteur hospitalier a partagé le besoin d’implémenter un cadre de travail, une méthode, pour gérer et contrôler la mise en œuvre du changement dans la gestion de portefeuille, des programmes et des projets. L’objectif est de renforcer les capacités à gérer la mise en œuvre des objectifs de transformation de manière efficace et efficiente.  

Pourquoi la gestion de projet est-elle aussi importante dans le secteur des soins de santé ?

Une série de statistiques indiquent la taille énorme du secteur de la santé en Suisse.
FacteurPourcentage
L'état de santé de la population âgée de 15 ans et plus dans les ménages privés en % (2017) : Problème de santé permanent32,7
Le taux d'hospitalisation pour 1000 habitants (2019)118,3
Taux de recours aux soins à domicile pour les personnes ≥ 80 ans, en % (2019).29,2
Nombre de lits d'hôpitaux/1000 habitants4.8
Nombre de médecins dans le secteur ambulatoire/1000 000 habitants222,3
(Chiffres fournis par l'Office fédéral de la statistique suisse https://www.bfs.admin.ch/bfs/en/home/statistics/health.html) Ces statistiques soulignent la quantité de travail dont les organisations de soins de santé ont besoin pour que la gestion de projet améliore continuellement les opérations dans un secteur aussi vaste. Les coûts des soins de santé en Suisse représentent 11,7 % du PIB, ce qui en fait le deuxième poste le plus élevé d'Europe. Dans l'enquête 2018 de l'Euro Health Consumer Index, la Suisse a été classée première et décrite comme ayant un excellent système de santé. Pour cette raison, la gestion de projet joue un rôle important dans le secteur hospitalier. Cependant, la gestion de projet dans les hôpitaux comporte des risques que d’autres secteurs ne connaissent pas, notamment tout ce qui est lié aux problèmes de sécurité: un projet de santé réalisé de manière inefficace peut avoir des répercussions néfastes sur la santé des patients.  

Défis de la gestion de projet dans le secteur médical

La gestion de projet dans le domaine de la santé est distincte car elle prend en compte la complexité et les risques à un tout autre niveau. Voici quelques-unes des principales différences avec les autres secteurs:
  1. Financement et optimisation
  2. Qualité et efficacité
  3. Diversité disciplinaire élevée
  4. Manque de ressources qualifiées
  5. Méthode de conduite du changement inefficace
 

1. Financement et optimisation

La gestion de projet aligne l’argent avec l’activité. Elle permet aussi de s’assurer que le financement des efforts est disponible aux différentes étapes du projet. Pour tirer le meilleur parti du financement disponible, le projet doit être optimisé, ce qui signifie allouer exactement la bonne quantité d’espace aux salles, aux blocs opératoires, aux salles de diagnostic, aux espaces publics et à d’autres installations afin de concevoir l’aménagement le plus rentable.

2. Qualité et efficacité

La réduction des coûts de gestion des soins a entraîné de nombreuses fusions et acquisitions dans le secteur hospitalier ainsi que de certains groupes médicaux dans le but de réaliser des économies d’échelle et d’offrir un service plus attractif économiquement. Il y a des ramifications plus dures et plus graves si les projets dépassent le budget ou dépassent le calendrier puisque le bien-être des patients peut être en jeu. Toute erreur ou absence de processus peut avoir des répercussions importantes sur la santé des patients. Le contrôle qualité est un élément majeur de la gestion de projet: dans le domaine de la santé, toutes les opportunités doivent être prises en compte pour l’efficacité dès le début du projet. Cela inclut de s’assurer que les conceptions architecturales et techniques sont alignées sur les objectifs budgétaires et fonctionnels du projet. La demande accrue de soins de santé, combinée à la hausse des coûts, a exercé une pression accrue sur l’industrie pour qu’elle fournisse des services économiques et de haute qualité. Essayer de trouver l’équilibre entre efficacité et qualité accorde encore plus d’importance à la nécessité d’une meilleure gestion de projet.

3. Diversité disciplinaire élevée

Les soins de haute technologie sont dispensés par des professionnels de la santé très spécialisés. Les équipes multidisciplinaires, surtout si elles n’ont jamais travaillé ensemble auparavant, sont susceptibles de manquer d’un langage commun. Les gens d’une même discipline partagent une signification commune pour les mots qu’ils utilisent et se comprennent. Mais, lorsqu’un certain nombre de disciplines sont impliquées – chirurgie, physiothérapie, travail social, soins infirmiers – les professionnels peuvent utiliser les mêmes mots et supposer à tort qu’ils signifient la même chose pour toutes les personnes présentes autour de la table. En termes de communication, ce qui se passe est une traduction erronée: une personne d’une discipline encode un sens pour un terme mais quelqu’un d’une autre discipline décode une signification différente. En conséquence, le message n’est pas compris. Cette question est particulièrement difficile à aborder dans l’équipe de soins de santé en raison de l’apparente simplicité de la terminologie. Cependant, le chef de projet doit toujours hypothétiser  que le personnel de différentes disciplines ne se comprend pas forcément et qu’il est crucial de donner et de recevoir des feedbacks. Poser des questions apparemment évidentes peut être très utile jusqu’à ce qu’un langage commun soit diffusé au sein de l’équipe. Le chef de projet doit s’assurer que les membres de l’équipe surmontent leur méconnaissance fonctionnelle et doivent affronter le scepticisme et la suspicion entre les fonctions avant que l’équipe puisse travailler efficacement.

4. Manque de ressources qualifiées

À mesure que le secteur des soins de santé évolue, le type de ressources nécessaires à la réussite des projets évolue également. La tendance actuelle à adopter la stratégie du bureau de gestion de projet (PMO) n’équivaut pas toujours à la capacité de mener avec succès des projets multi-organisations, de travailler côte à côte avec les cliniciens pour modifier la prestation des soins ou évaluer l’impact d’une réglementation importante. Une équipe de projet sans les compétences et l’expérience nécessaires, y compris l’expertise de l’industrie des soins de santé, échouera forcément. Pour en savoir plus sur la mise en place d’un PMO dans le secteur hospitalier consultez notre interview de Maddy Silverans. → Les défis de la gestion de projet dans le secteur hospitalier

5. Méthode de conduite du changement inefficace

La pression pour changer rapidement est particulièrement palpable dans les soins de santé, car les organisations qui ont historiquement «évolué vers» le changement doivent maintenant utiliser une méthodologie de changement pour réussir. Souvent, les projets n’incluent pas de flux de travail dédié à la préparation de l’organisation à un changement significatif. La communication du changement est particulièrement difficile en raison de la dichotomie politique entre les médecins et l’administration. Le résultat est un manque de compréhension, d’acceptation et finalement d’adoption du changement, conduisant à des projets ratés. Une série d’autres problèmes affectent l’industrie en constante évolution – des questions pour lesquelles la gestion de projet est de plus en plus vitale. Ces problèmes sont les suivants:
  • La diminution des paiements des programmes de santé gouvernementaux et des compagnies d’assurance privées a contraint les organisations de soins de santé à trouver des moyens d’économiser de l’argent.
  • Les systèmes nouveaux et complexes de dossiers de santé électroniques sur les patients doivent être surveillés et améliorés en permanence.
  • Les nouvelles technologies doivent également être suivies et améliorées.
  • De nouvelles réglementations continuent d’émerger.
  • Les établissements de santé font l’objet d’une surveillance accrue des diverses parties prenantes externes, y compris le gouvernement, les compagnies d’assurance maladie et les patients.
 

Avantages de la gestion de projet dans le secteur hospitalier

Une gestion de projet solide contribue à améliorer les soins de santé et le secteur de la santé de plusieurs manières. En effet, la gestion de projet peut effectuer les opérations suivantes:
  • Assurer que la composition technique de l’équipe de projet est basée sur l’objectif du projet. Si l’objectif est de réduire les coûts, le chef de projet doit s’assurer que tous les membres connaissent la mesure des coûts et la comptabilité.
  • Assurer que les membres de l’équipe sont à un niveau suffisamment élevé dans leur organisation respective pour que les recommandations aient une forte probabilité d’être mises en œuvre.
  • Assurer que les politiques d’intégration ne sont pas sous-estimées. Ce n’est que lorsque les membres de l’équipe se rendent compte que soit tout le monde réussit ensemble ou soit tout le monde tombent ensemble, que le travail du projet peut commencer.
  • Assurer que les membres de l’équipe se rapportent véritablement les uns aux autres en tant que pairs. La hiérarchie ne doit pas interférer avec les relations entre pairs de l’équipe. La ou les personnes qui dirigent l’équipe dans la résolution d’un problème particulier devraient être le membre possédant les connaissances et l’expérience pertinentes, plutôt que la personne au sommet de la hiérarchie implicite.
  • Favoriser la qualité des soins en améliorant les processus utilisés pour fournir ces soins.
  • Améliorer la communication entre le personnel soignant soignant les patients.
  • Améliorer la planification organisationnelle.
  • Faciliter la budgétisation, car une gestion de projet solide alloue directement les ressources nécessaires aux travaux importants.
  • Soutenir les processus mis en place pour réduire le risque de poursuites – en grande partie parce que des processus améliorés augmentent la qualité des soins.
  • Encourager les relations avec les parties prenantes, y compris les assureurs, les agences gouvernementales, les patients et autres.
  • Augmenter la productivité du personnel
  • Atténuer les risques et les problèmes juridiques.
Lire plus
Date: 20/05/2021
Karine est Project Leader & Team Leader chez Smals. Elle est spécialiste des outils collaboratifs et est responsable du centre de compétences SharePoint de Smals.  

Quelle est votre fonction actuelle, quelles sont vos missions ?

Je suis responsable du centre de compétences SharePoint chez Smals, l’organisation ICT commune des institutions publiques belges de sécurité sociale. Je suis chef de projets en charge de mener à bien les projets SharePoint qui nous sont confiés par nos membres.  

Comment avez-vous connu Agile PM, quel était votre besoin initial ?

La formation Agile PM fait partie de notre catalogue de formation. Je cherchais une méthode agile et je savais que l’approche SCRUM, aussi utilisée chez Smals, vise essentiellement à répondre au besoin d’organisation des équipes de développement. Nous avions essayé de mettre en place cette approche sur les projets SharePoint mais cela n’avait pas été convaincant. Je cherchais une approche plus globale, intégrant aussi la gestion de projet, qui permettrait de mieux impliquer les représentants du métier sur nos projets, d’être certains de travailler sur des choses qui ont de l’importance.  

Peu de temps après la formation vous avez géré avec succès un projet d’une certaine envergure. Pouvez-vous nous expliquer le contexte du double projet ?

Smals soutient et seconde les organismes du secteur social et du secteur des soins de santé – ainsi que d’autres services publics à leur demande – dans leur gestion de l’information afin qu’ils puissent offrir une prestation de services efficace et effective à leurs utilisateurs. Smals met ses compétences à disposition pour être réutilisées dans le but de générer des effets d’échelle mutuels et une plus grande valeur ajoutée. Le premier projet sur lequel nous avons appliqué l’approche Agile PM concerne une institution de la sécurité sociale belge qui cherchait à renouveler deux applications, qui existaient auparavant en Lotus Notes, en applications SharePoint. Il s’agissait de deux gros projets pilotes (une application de gestion de demandes et un portail de communication interne), qui devaient en outre leur permettre de développer leurs compétences Sharepoint et leurs compétences en gestion de projet avec Sharepoint. Nous avons mis en place l’approche de projet agile AgilePM avec ce membre et tout s’est très bien passé, nous avons été très satisfaits pour de nombreuses raisons. Suite à ma formation, j’ai formé un de mes collègues qui jouait le rôle d’architecte/ développeur/coach technique vis-à-vis du membre. Le but était que cette personne développe et paramétrise un certain nombre d’éléments tout en travaillant avec l’équipe à former pour que les collaborateurs de cette équipe participent également au développement du projet. Nous avons briefé nos interlocuteurs business (business ambassador) et techniques (les développeurs) lors d’un même kick off pour les deux projets. J’ai expliqué la méthode, quels sont les rôles et responsabilités de chacun, comment cela allait fonctionner et à la fin du kick off nous avons donné pour mission au business de faire une première version du backlog en décrivant leurs exigences et en les priorisant selon la technique MOSCOW. Le challenge était de désigner 60% de l’effort total du projet comme étant des musts, ce qui est souvent difficile (souvent on obtient 70 voire 80% d’exigences en must au premier round).  

Quelles étaient vos contraintes, vos challenges ?

Le premier challenge était celui du coaching, puisqu’une partie de l’équipe n’était pas mon équipe habituelle. Ensuite mon deuxième challenge était de m’assurer que l’ensemble de l’équipe de projet suit bien, comprend les règles, la vision, les enjeux. Un des développeurs, qui était par ailleurs très bon techniquement, n’était par exemple pas convaincu par la méthode AgilePM, il était un peu sceptique au départ, mais il a finalement joué le jeu et a pu constater que cette approche ne marchait pas si mal et que les relations avec le business se sont très bien passées. Les clients ont d’ailleurs apprécié travailler en mode agile grâce à la méthode Agile PM, qui permet d’inclure beaucoup plus le business dans le projet et des décisions au jour le jour. Parfois, le business pense que quelque chose est simple mais le fait d’être impliqué lui permet de se rendre compte des difficultés réelles ; à l’inverse les développeurs comprennent mieux les besoins sous-jacents. La méthode AgilePM permet d’avoir un dialogue en toute transparence et de faire les bons choix, sans que les équipes de développement ne s’acharnent sur des choses qui ne sont pas si importantes que cela pour le business. Les clients attendaient que le projet aille vite et souhaitaient obtenir des résultats rapidement sans pour autant avoir fixé une deadline (ce qui peut être un piège puisqu’il est possible de mettre beaucoup plus longtemps que nécessaire). Nous avons toutefois réussi à livrer rapidement et en 3 mois nous étions prêts à partir en production. Il y a eu des problèmes de performance réseau qui ont empêché d’être live comme prévu mais nous étions prêts.  Nous avons simplement préféré attendre et résoudre le problème de réseau plutôt que de livrer un outil qui aurait été perçu comme peu performant, même si la cause était externe à l’outil.  

Comment avez- vous implémenté la méthode ?

Après avoir réalisé le coaching et le kick off, nous avons mis en place des réunions de sprint review/sprint planning toutes les deux semaines pour chacun des projets, ce qui revenait à traiter un projet une semaine et l’autre la semaine suivante et ainsi de suite. Il y a avait un des deux business ambassador qui participait d’office aux réunions de l’autre pour assurer une certaine consistance dans les décisions, vu qu’on travaillait sur la même plateforme technique. Tous les jours, il y avait également une réunion de standup de 15 minutes impliquant l’équipe de projet (interlocuteurs business et techniques). Nous organisions un project board tous les mois d’une heure et cela suffisait pour suivre l’avancement du projet. Il est important de ne pas trop rentrer dans les détails fonctionnels ou techniques durant les project board, mais de rester concentré sur le suivi du projet. Une fois cette structure de suivi mise en place, le projet s’est déroulé tout seul ou presque ! A la fin du projet, nous avons réalisé un lessons learned à distance et le feedback du client qui est ressorti est qu’au départ ils n’avaient pas forcément bien compris ce qui avait été expliqué lors du kick off, ni pourquoi nous demandions certaines choses, mais au fur et à mesure tout s’est éclairci, ils ont compris pourquoi et la raison de l’intensité des efforts. Pour un prochain projet il faudrait être plus attentif à cette dimension là. Le client n’était pas non plus conscient au départ de l’effort que cela allait lui demander de son côté. Être business ambassador est un travail à quasi temps plein et il faut pouvoir dégager du temps aux personnes qui reçoivent cette mission, pour qu’elles puissent mener à bien leur engagement. Il y a un rythme de réunion à suivre, mais il faut aussi répondre aux questions de l’équipe de développement au jour le jour, participer aux tests, etc.  

Comment la méthode AgilePM vous a-t-elle aidée ? Quelle partie vous a été la plus utile ?

Le plus utile selon moi reste la technique de priorisation MOSCOW. Il y a une grosse différence entre classer les exigences selon un ordre (1-2-3-4-5) et accepter qu’une exigence qu’on estime tout de même importante ne soit finalement qu’un “should” qui peut-être ne sera jamais implémentée… parce que d’autres exigences passent avant. La priorisation continue, c’est sans doute LE point le plus utile. Naturellement il n’y a pas que cela, la méthode dans son entièreté est utile.  

Avez-vous des conseils pour les professionnels du secteur ?

Il faut se former. Je recommande de suivre une vraie formation avec un expert et non pas simplement de regarder, lire le livre et picorer des éléments en fonction de ce qui nous parle. J’ai suivi une formation en petit groupe de 4 ou 5 et cela m’a permis de bien comprendre la méthode, d’avoir des templates et de poser mes questions. Personnellement sans la formation je n’aurais jamais lu tout le manuel en entier et je serais passée à côté des bienfaits de la méthode.  

Un petit mot pour conclure ?

Récemment j’ai aussi suivi une formation DevOps et je vois que les deux s’articulent bien ensemble puisque la philosophie et la culture sont similaires.  

Karine Picart

agile pm Karine Picar Karine est Project Leader & Team Leader chez Smals. Elle est spécialiste des outils collaboratifs et est responsable du centre de compétences SharePoint de Smals. Suivez Karine sur Linkedin
Lire plus
Découvrez nos évènements gratuits

Restez connecté à la communauté
Suivez-nous sur Linkedin e Twitter

Lire les dernières news
Voir les prochains évènements
Go to Top