Actualité

Davina Leysen travaille comme coordinatrice de projet chez Belnet. Elle est certifiée P3O et PRINCE2 et prévoit d'obtenir bientôt sa certification MSP.  

Quelle est votre fonction actuelle ? Quelles sont vos missions ?

Mon titre officiel : Coordinatrice de projets chez Belnet. En regardant les définitions de P3O, ma fonction peut être décrite comme Project and Programme Officer. Je soutiens non seulement notre Programme Manager mais également nos chefs de projet. En pratique, cela signifie maintenir notre base de données de portefeuille à jour, l'organisation du comité de projet, la gestion des ressources et le soutien global à tous les gestionnaires de programme et de projet. Si nécessaire, je peux également effectuer certaines activités de gestion de projet.  

Comment êtes-vous arrivée à effectuer une carrière en gestion de projet, programme et portefeuille ?

J'ai d'abord été embauchée en tant que membre de notre service achats. Dès que j'ai commencé à travailler chez Belnet, j'ai été détachée pour travailler sur un grand projet. Mon travail dans ce projet était de suivre la livraison de toutes les commandes. Ce grand projet a été le catalyseur de la création d'un PMO au sein de Belnet. En étant témoin de l'approche de ce grand projet et de la création du PMO de première main, et tout simplement en appréciant le travail que je faisais, j'ai demandé si je pouvais rester en tant que membre permanent du nouveau bureau de gestion de projets.  

Quel est le plus gros problème / changement que vous voyez dans la communauté de gestion de projet en ce moment?

La gestion de projet est parfois (trop souvent) considérée comme un «dernier recours». Les demandes de démarrage d'un projet proviennent souvent d'un problème de planification et d'actions coordonnées. Pour cette raison, les projets doivent être lancés très rapidement et il n'y a pas toujours la possibilité de planifier et de documenter tout comme il se doit. Il en résulte alors des virages inattendus et des retards possibles au cours du projet.  

Quels conseils donneriez-vous pour affronter ce challenge ?

Le PMO a su combler le manque à gagner et prendre la relève ces dernières années, avec un résultat globalement positif. Notre travail a été apprécié car nous avons fait avancer les choses, ce qui a conduit à une vision plus positive de notre travail. Dans l'ensemble, les aspects positifs et la valeur ajoutée de la gestion de projet sont de plus en plus connus au sein de Belnet. Pour les changements importants et à grande échelle, le PMO est consulté à un stade précoce, de sorte que les avantages de l'adoption de l'approche projet soient élevés et reconnus. On voit vraiment un changement dans la perception de l'approche de gestion de projet. Nous avons remarqué qu’après la création du PMO, les autres départements pensaient que la gestion de projet était «trop administrative» et ralentissait le travail qui devait être fait. C'était une perception, qui venait du simple fait de ne pas savoir ce que nous faisions, pourquoi nous travaillions comme nous le faisions et comment cela ajouterait de la valeur aux résultats.  

Comment avez-vous impliqué tous vos collaborateurs pour créer une approche commune?

Nous avons travaillé sur la transparence et la communication avec l'ensemble de l'entreprise. Les RH nous ont donné la possibilité de créer notre propre page sur l'intranet, accessible à tous. Nous publions nos procédures, la documentation approuvée (l’exposé du projet, la DIP, le business case,…), ... La communication et la transparence sont essentielles dans notre travail quotidien, nous sommes toujours ouverts à recevoir les commentaires de nos collègues et à prendre des mesures pour répondre adéquatement à leurs questions.  

Comment appliquez-vous P3O et à quoi ressemble la structure?

Chaque trimestre, nous organisons une session d'information sur les projets (Project Information Session), où nous annonçons les projets nouveaux, les changements majeurs, les projets clôturés et nous présentons entre 2 et 4 projets plus en profondeur. Notre nouvel «outil» de communication que nous avons présenté est la fiche d’information sur le projet (Project Information Sheet). Il s'agit d'un document de 2 pages qui explique le projet de manière compréhensible pour tous - du service achats aux techniciens du service réseaux. Au cours des deux derniers mois, nous avons également installé un groupe de consultation, où différents services sont impliqués, appelé la réunion des demandes clients (Customer Demand Meeting). Au cours de cette réunion, différentes demandes de clients à venir ou récemment reçues sont discutées et la meilleure approche (Project or Business as Usual) est convenue. Nous pouvons mieux anticiper ce qui nous attend, et la collaboration transversale entre les équipes renforce notre mandat d'exécution des projets.  

Citez trois notions que vous souhaiteriez apprendre dans un proche avenir pour vous développer en tant que professionnel ?

Améliorer mes compétences en conduite du changement Comme mentionné précédemment, nous avons commencé notre premier programme. Cela va entraîner un grand changement pour une grande partie de l'entreprise - presque tout le monde devra adapter sa façon de travailler d'une manière ou d'une autre. J'ai vu de mauvais et de bons exemples de gestion du changement au cours des trois dernières années. Une gestion du changement bien organisée a la capacité d'augmenter de façon exponentielle les résultats positifs d'un projet.   Améliorer mes compétences sur Excel Les outils spécialisés pour la gestion de projet / portefeuille (utilisés pour le reporting, le budget,…) sont souvent très chers. Nous essayons de repousser les limites d'Excel autant que possible, aussi longtemps que possible. Cela entraîne la nécessité d'une formation pour maîtriser les macros, créer des tableaux croisés dynamiques et bien d'autres fonctions très utiles.   Améliorer la gestion des ressources À l'heure actuelle, nous avons une feuille de temps prévisionnelle des ressources et une sur les ressources réelles de main-d'œuvre pour les projets. Pour les tâches opérationnelles, il n'y a pas de système à l'échelle de l'entreprise. Pour le moment, cela reste une tâche exécutée manuellement de copier-coller des données individuelles dans un fichier consolidé, avec une certaine marge d'erreur humaine. Pour minimiser ces erreurs, j'ai collaboré avec notre département informatique pour automatiser la consolidation. Une prochaine étape consistera à introduire un système de pool de ressources pour l'ensemble de l'entreprise. Cela devrait nous permettre de planifier tous les projets de notre portefeuille. Si nous savons combien de temps les employés auront besoin pour leurs tâches opérationnelles, nous connaîtrons la capacité qui reste pour les projets et nous pouvons estimer la durée de chaque projet. En revanche, si un projet a une priorité élevée, nous pouvons voir où des adaptations dans la division du travail opérationnel sont possibles.  

Davina Leysen

Davina Leysen travaille comme coordinatrice de projet chez Belnet. Davina a créé une base de support pour la mise en œuvre et l'utilisation de la structure P3O chez Belnet. Elle est certifiée P3O et PRINCE2 et prévoit d'obtenir bientôt sa certification MSP.

Si vous avez récemment obtenu votre certification ITIL 4 Foundation, tout d'abord félicitations ! Mais une fois certifié(e), vous vous demandez certainement : et maintenant ? Après avoir obtenu la certification ITIL Foundation, vous avez trois possibilités, trois voies à suivre :

• Arrêter
• Mettre en pratique ce que vous avez appris
• Poursuivre la formation

Puisque nous avons peu à ajouter sur la première option, regardons plutôt les deux dernières options, qui peuvent d’ailleurs être exécutées séparément ou simultanément.  

De la théorie à la pratique

Pour éviter que votre certification ne reste qu’un bout de papier et vos efforts ne soient pas vains, quelques règles doivent être respectées. Sans implication forte de la direction, mais aussi du personnel, le passage à la pratique ne verra jamais le jour. Pour assurer la participation de tous, la communication reste incontournable, dès le retour de votre formation. Vous devez alors jouer un rôle de premier plan et démontrer ce que vous avez appris durant votre formation. En effet, bien que beaucoup reconnaissent l'importance de démontrer les nouvelles compétences acquises et la valeur ajoutée qu'elles peuvent apporter à l'organisation, nous oublions souvent de les partager avec des collègues et des membres juniors de l'équipe. Il est d’autant plus essentiel d'avoir l'approbation de la direction et de veiller à ce que les nouvelles approches soient intégrées dans l'organisation, vous devez ainsi agir comme un ambassadeur et donner de la visibilité au cadre de référence. Les étapes qui suivent la formation sont:

• Vérifier à quelle étape du cycle de vie se situe votre organisation

Y a-t-il des choses que vous ne faites pas qui pourrait vous aider?

• Chercher des avantages à court terme:

Où pourriez-vous faire la différence? Comment montrer à votre management le retour sur investissement de votre formation? Il est toujours important de se rappeler qu'ITIL n'est pas normatif. Il n'y a pas de "formule magique" qui vous rendra conforme à ITIL, il est donc important de comprendre où vous pouvez apporter des améliorations et comment tirer le meilleur du guide pratique.  

Continuer la formation

L'autre voie possible consiste à poursuivre votre "parcours" ITIL à travers la formation et la certification. Dans ce cas, il est important d'être bien informé des possibilités et des parcours que vous pouvez emprunter. Nous essaierons de vous accompagner dans cette démarche: vous trouverez sur notre blog et sur notre site des informations, des idées, des astuces et des expériences qui vous aideront à vous orienter au mieux dans votre "parcours ITIL". Si vous êtes certifié ITIL v3 Foundation, nous vous recommandons de passer à la nouvelle version ITIL 4, lancée en 2019. Si vous êtes certifié ITIL 4 Foundation, nous essaierons de comprendre ensemble quel peut être votre parcours.  

Quel est le parcours idéal pour moi?

Comprendre quel est le parcours idéal pour vous, professionnellement et personnellement, fait partie intégrante de votre "cheminement". Dans la version 3 du cadre de référence, vous pouvez choisir de combiner les niveaux intermédiaires du Lifecycle et Capability pour ensuite passer l'examen MALC (Managing Across the Lifecycle). Maintenant, avec la version 4, vous pouvez choisir entre deux parcours:

• ITIL Managing Professional (ITIL MP) : 4 modules
• ITIL Strategic Leader (ITIL SL) : 2 modules

Les modules du parcours Managing Professional fournissent des connaissances pratiques et techniques qui peuvent vous aider à gérer avec succès les services informatiques, les équipes et les flux de travail alors que le parcours ITIL Strategic Leader se concentre davantage sur la manière dont l'IT influence et oriente les stratégies d’entreprises.   Les 4 modules ITIL MP sont tous disponibles:

• Create, Deliver & Support
• Direct, Plan & Improve (module commun aux deux parcours)
• High Velocity IT
• Drive Stakeholder Value

En ce qui concerne le parcours ITIL SL, un seul module Direct, Plan & Improve est pour le moment disponible, l'autre (Leader Digital and IT Strategy) sera lancé au cours de l’année 2020. Une astuce consiste également à en discuter au sein de l’entreprise, en examinant les besoins et en évaluant les ressources et les exigences que vous pourriez aider à satisfaire grâce à votre parcours ITIL. Suivez le parcours qui reflète vos motivations à poursuivre la formation, les besoins de votre organisation et vos intérêts. Quel que soit le parcours que vous choisissez, la chose la plus importante est de ne pas vous arrêtez. Maintenant que vous avez obtenu la certification ITIL Foundation, la prochaine phase de votre montée en compétences commence. Demandez-vous : "Où est-ce que je veux arriver dans ma carrière?" et décidez du parcours qui vous convient le mieux pour arriver à votre objectif.  

Comment QRP peut-il vous aider ?

Le choix de votre parcours ITIL est une étape importante - Nous avons mis à votre disposition diverses documentations et ressources multimédias pour vous aider. En voici quelques exemples:

• Notre article Comment s’y retrouver dans le parcours de formation ITIL 4 ? fournit de plus amples informations sur les modules intermédiaires ITIL 4.
• Pour aller plus loin : notre expert Kais Albassir a présenté les 4 modules du parcours Managing Professional lors de mini webinaires en français. Visionnez gratuitement les replay sur notre chaine webinaire QRP International
• Nos pages formations fournissent également de nombreuses informations pratiques, pour effectuer votre choix.

Enfin et surtout, si vous avez toujours des doutes, vous pouvez contacter notre conseillère formation au +41 43 588 10 36 afin d’exposer votre projet et obtenir des conseils adaptés à vos besoins spécifiques.

Le SCRUM Developer doit à la fois comprendre les principes SCRUM et avoir la capacité à mettre en application ses compétences d’ingénierie agile, grâce à cette formation complète alliant théorie et exercices de mise en application des compétences techniques.  

Définition « SCRUM Developer »

Le Développeur SCRUM est le professionnel responsable de la création des livrables du projet, avec toute l'Équipe de Développement. Comme décrit dans le Guide SCRUM, il existe trois rôles principaux, responsables de la réalisation des objectifs du projet, dans SCRUM : le Product Owner, le SCRUM Master et l’Équipe de Développement. L’Équipe de Développement est constituée de professionnels qui livrent à chaque sprint un incrément « terminé » et potentiellement livrable du produit. Seuls les membres de l’Équipe de Développement créent l’incrément.  

Le rôle du Développeur SCRUM

• Comprendre les exigences business, spécifiées par le Product Owner
• Estimer les user stories dans le backlog de sprint
• Développer le produit / service (livrables)

Chaque SCRUM Developer est responsable de la livraison d'un élément fonctionnel (ou morceau) du produit à la fin de chaque sprint.  

Les responsabilités de l’Équipe de Développement SCRUM et des Développeurs

Lorsqu'ils travaillent pour un projet SCRUM, les Développeurs ont diverses responsabilités :

• Atteindre les objectifs définis pour chaque sprint
• Assister aux réunions “daily SCRUM” (mêlées quotidiennes) rapportant les tâches planifiées pour la journée
• Assurer au Product Owner et au SCRUM Master que le travail alloué est exécuté comme prévu
• Garantir une compréhension claire des epics pour chaque persona
• Fournir des inputs au Product Owner lors de la création de user stories
• Comprendre les user stories
• Estimer les user stories approuvées par le Product Owner
• Valider les user stories à faire dans le sprint et développer la liste des tâches en fonction de celles-ci
• Signaler au SCRUM Master les éventuels obstacles, s’opposant à l'avancement du projet
• Convenir de la durée du sprint avec les autres rôles principaux de l’équipe SCRUM
• Développer le sprint backlog et le burndown chart
• Créer les livrables
• Mettre à jour le burndown chart, le SCRUM board et la liste des obstacles
• Soumettre des demandes de changement, si besoin
• Participer aux revues du backlog
• Identifier les opportunités d'amélioration à partir du sprint actuel et convenir des améliorations possibles pour le prochain sprint
• Participer aux rétrospectives de sprint.

 

Les compétences du SCRUM Developer

Un Développeur SCRUM devrait avoir:

• des connaissances et compétences techniques (analyse de logiciels, codage, programmation de logiciels ou tests)
• une connaissance approfondie du framework SCRUM et une compréhension de la façon de l'implémenter efficacement pour tout projet
• un bon esprit d'équipe, nécessaire pour favoriser une collaboration efficace avec les autres membres de l'équipe.

Le Guide SCRUM met en évidence d'autres soft skills et identifie un bon Développeur comme étant :

• motivé
• proactif
• auto-organisé
• indépendant
• responsable
• intuitif
• axé sur les résultats.

  Sources: Schwaber and Sutherland, The Scrum Guide; © 2017 SCRUMstudy™. A Guide to the Scrum Body of Knowledge (SBOK™ Guide).

Selon le rapport d'étude d'Axelos, la moitié des chefs de projet qui ne font pas ou rarement de revues de projet ont connu un échec de projet au cours des 12 derniers mois - contre 34% de ceux qui effectuent toujours ou souvent des revues. Ces données nous amènent à donner encore plus de poids au concept de «lessons learned» (leçons tirées de l’expérience), qui devrait faire partie intégrante de la gestion de projet.  

Pourquoi les “lessons learned” sont-elles souvent négligées?

Les chefs de projet ne veulent pas «échouer». Au début du projet, les chefs de projet sont entièrement concentrés sur sa réalisation - le concept d'échec n'est même pas pris en considération. La pression des entreprises pour l’obtention de résultats tangibles ajoute une plus grande dynamique vers le point d'arrivée - même si cela signifie prendre des raccourcis. Avec toutes les énergies concentrées sur le point d'arrivée, il est difficile de reconnaître l'échec à n'importe quel niveau - malgré le business case. Une fois le projet terminé, l'instinct naturel est d'aller de l'avant et de se concentrer sur le prochain défi. Si la culture au sein de l’organisation conduit à célébrer le succès plutôt qu'à prendre du recul pour voir ce qui aurait pu être mieux fait, ce changement ne se produira jamais. Avec autant de leçons tirées de l'expérience de chaque projet, il est dommage que tous ces enseignements soient simplement effacés à la fin du projet.  

Pourquoi est-il important pour une organisation d'encourager les employés à partager ce qu'ils ont appris au cours d'un projet (à la fois positivement et négativement)?

Tout d'abord, le partage de “lessons learned” contribue à promouvoir l'engagement des employés. Investir du temps dans l'écoute démontre un leadership solidaire et favorise un environnement de travail positif - deux facteurs très positifs au sein d'une organisation. D’ailleurs, s'il est géré correctement, le partage de “lessons learned” peut être plus efficace et moins coûteux que les autres outils de team building. Une organisation qui demande à chacun de fournir des commentaires et d'exprimer des opinions de manière formelle, peut faciliter l’écoute et développer l’empathie des membres de l'équipe, et donc une meilleure compréhension de chaque rôle et de la façon dont ils travaillent ensemble pour atteindre les objectifs. Sur le plan pratique, fournir un espace où les gens peuvent parler de leurs problèmes signifie que chaque problème est résolu rapidement et que les voix potentiellement négatives sont redirigées vers une conversation beaucoup plus productive. Il est cependant essentiel que les organisations ne se contentent pas de simples déclarations. Chaque leçon apprise pendant le projet doit être documentée et archivée de manière à être disponible pour les futurs projets. Le principe PRINCE2 “Leçons tirées de l'expérience” reprend des Bonnes Pratiques très utiles, s'il est suivi correctement. Ce n’est donc pas un simple exercice de rédaction. Guidé par le chef de projet, l’enregistrement des “Leçons tirées de l’expérience” doit être utilisé dès le début du projet, et considéré comme un document à utiliser tout au long du projet et non comme quelque chose à revoir à la fin, lorsque la plupart des informations ont été oubliées. Sa véritable valeur réside dans le partage de ces enseignements entre de nombreux chefs de projet, afin qu’ils deviennent partie intégrante de l'ADN de l'équipe.  

3 conseils aux chefs de projet :

Donner de la valeur aux “lessons learned” Si le chef de projet ne prends pas le temps d’évaluer les résultats des leçons apprises, personne d'autre ne le fera. Il est donc important d'organiser une ou plusieurs sessions au cours desquelles la voix de chacun sera entendue.</li> Considérer un médiateur Il peut être judicieux de demander à quelqu'un d'autre de diriger la réunion. L'établissement de règles de base suggère un espace neutre où chacun peut discuter de ses problèmes.</li> Se concentrer sur l'amélioration: La clé de ce principe est l’objectivité de chacun; ce n'est pas une réunion pour pointer du doigt quelqu'un ou le blâmer. L'objectif est de créer une confiance mutuelle dans le processus de gestion et de croire en la valeur des résultats.  

Une nouvelle mentalité

L'échec n'est pas quelque chose à craindre. Ce ne devrait pas être un sujet tabou, mais plutôt faire partie de la progression et de l'autonomisation d'une équipe par de nouvelles façons de penser. De nombreux entrepreneurs prospères sont arrivés où ils sont, grâce à ce qu'ils ont appris de leurs propres erreurs. L’efficacité réside simplement dans la  prise de recul et l’analyse de ses erreurs afin d’éviter de reproduire les mêmes erreurs et pouvoir faire différemment la fois suivante. Pour citer Samuel Beckett: "Déjà essayé. Déjà échoué. Peu importe. Essaie encore. Échoue encore. Échoue mieux."   Téléchargez votre modèle de document personnalisable: PRINCE2 2017 Leçons tirées de l'expérience (Lessons learned) Ce document très utile, disponible au format Word, vous aidera dans la réalisation de votre projet PRINCE2 !  

Dans un projet virtuel, les membres de l’équipe travaillent tous à différents endroits. Nous avons constaté qu’au cours des dernières années, les équipes de projet ont évolué pour devenir toujours plus «virtuelles» - conditions de travail plus flexibles, fournisseurs et partenaires externes, équipes externalisées - mais la communication reste le plus grand obstacle. Communiquer efficacement avec l’équipe de projet est encore plus compliqué lorsque l’équipe n'est pas physiquement située au même endroit. Il y a beaucoup de difficultés dans les aspects «soft» de la communication : vous manquez souvent les indices visuels qui vous aident à comprendre comment un message oral est reçu. Dans la communication écrite, ceux qui envoient le message ont tendance à être plus négatifs et ceux qui le reçoivent ont souvent tendance à l'interpréter de manière plus négative que nécessaire. La partie la plus difficile de la communication à distance consiste à créer une boucle de rétroaction qui garantit qu'un message est reçu et interprété de la bonne manière. Quant à la dynamique de communication, l'approche dans un environnement virtuel doit être similaire à celle dans laquelle tout le monde travaille au même endroit. Le problème est que de nombreuses inefficacités émergent à distance - ce qui n’arriverait pas ou peu lorsque vous êtes au même endroit, puisque vous pouvez facilement rencontrer votre collègue ou aller directement à son bureau. Mais comme toujours : le temps passé à la préparation est du temps gagné à l'exécution. Ce dont votre projet a besoin - virtuel ou classique - est une approche de gestion de la communication.  

L'approche de gestion de la communication PRINCE2

Comme dans de nombreux autres aspects de la gestion de projet, PRINCE2 fournit des conseils sur la façon de faire face aux défis de communication. La méthode de gestion de projet PRINCE2 est désormais une norme de facto dans de nombreuses régions du monde. Et en ce qui concerne la communication, elle fournit des conseils grâce à l'approche de gestion de la communication et indique également comment l'utiliser tout au long du cycle de vie du projet. PRINCE2 est souvent considéré comme “rempli de documentation” et de bureaucratie, mais ce n'est rien de plus qu'une interprétation déformée. Je préfère utiliser PRINCE2 comme liste de contrôle des choses que je dois clarifier et convenir avec les parties prenantes du projet. Ma citation préférée du manuel PRINCE2 (à la page 27) dit qu’il est “important de se rappeler qu'une gestion de projet efficace nécessite des informations (pas nécessairement de la documentation) et des décisions (pas nécessairement des réunions)". La situation détermine ensuite dans quelle mesure ces informations doivent être bien documentées et si les décisions doivent être prises en réunion ou non. Voyons ce que propose l'approche de gestion de la communication de PRINCE2 et comment elle peut aider à gérer des projets virtuels. À strictement parler, l'approche de gestion de la communication traite des moyens et de la fréquence de la communication avec les parties intéressées à l'intérieur et à l'extérieur du projet. Je n'entrerai pas dans les détails sur l'identification, l'analyse et l'implication des parties prenantes externes, mais je me concentrerai sur la communication interne, par exemple avec l'équipe de projet.  

Outils et techniques

PRINCE2 ne traite pas les outils, vous ne trouverez donc pas de recommandations ou de conseils particuliers sur cette question. Mon conseil est seulement "n'y pensez pas trop". Après tout, "un fou avec un outil est toujours un fou". Évaluez donc d'abord les outils déjà utilisés par votre organisation. Ne dépendez pas trop des e-mails ; les e-mails ne sont pas un bon outil en général, mais il est difficile d'éliminer cette mauvaise habitude. Les e-mails ont tendance à entraîner une surcharge de communication. Il est beaucoup plus utile d'utiliser des outils tels que le chat pour la communication écrite, il est plus informel et réduit considérablement l'effort dû au format. Cela laisse donc plus de temps pour le contenu. En plus du chat, il est également bon d'avoir un outil pour les réunions en ligne, pour les vidéoconférences, auquel tout le monde peut facilement accéder à partir de différents appareils. L'option de partage d'écran est généralement incluse et est très utile. Il est important pour les membres de l’équipe, d'être tous d’accord et alignés sur la façon d'utiliser le ou les outils. En tant que chef de projet, vous devez clarifier les directives et donner le bon exemple. Quelques points à considérer : l'utilisation de webcams ou du bouton muet pour la visioconférence, comment structurer le sujet et l'utilisation de mentions dans les chats. Assurez-vous également qu'il soit clair pour tout le monde quel outil sert à quoi - cela est particulièrement important lorsqu'il existe plusieurs outils disponibles qui ont à peu près la même fonctionnalité.  

Rapport

Vous devez garder une trace, enregistrer les communications : décisions prises, actions convenues, sujets à discuter... Je le répète, le courrier électronique n'est pas un bon moyen. Mais vous n'avez pas besoin d'outils spéciaux : un simple document partagé sur le réseau auquel tout le monde peut accéder peut suffire. Assurez-vous que tout le monde sache où trouver ces informations. Ici aussi, il est peut-être plus facile et plus sûr d'utiliser la technologie que votre organisation possède déjà que d'acheter de nouvelles solutions.  

Calendrier

Déterminez quand vous ou d'autres communiquerez, puis les réunions que vous ferez. Les réunions en ligne ont tendance à être beaucoup plus fatigantes que les discussions en direct, et les personnes qui travaillent à domicile ont généralement d'autres distractions, comme les enfants. Dans un environnement virtuel, il est donc encore plus important de limiter le nombre de réunions au minimum ! Des rôles et des responsabilités clairs et des résultats bien définis aideront à réduire le nombre de sessions en ligne avec plusieurs personnes. Assurez-vous de suivre les principes PRINCE2 même dans des environnements virtuels; (quels principes ? Lire l'article de blog Les principes PRINCE2 appliqués aux projets virtuels).  

Rôles et responsabilités

Assurez-vous qu’il est clair pour tout le monde qui est responsable pour quel type de communication. Cela signifie non seulement d'organiser des réunions ou de gérer le chat en groupe, mais aussi de préciser qui doit répondre à quel type de question. Plus vous clarifiez ces choses en amont, plus votre projet sera facile.  

Communication informelle

Tout ce dont nous avons parlé jusqu'à présent concerne principalement la communication formelle. Lorsque je coache des chefs de projet, je recommande souvent de choisir un bureau près de la cafetière. Mais à domicile, cela n'a pas beaucoup de sens. Au bureau, la machine à café a une fonction informelle de sollicitation, de promotion de la conversation: vous pourrez comprendre l'état actuel, les risques et problèmes réels du projet et ce que l'équipe projet apprend. Alors, n'oubliez pas ces moments - essayez de les inclure dans votre routine. Dans un environnement virtuel, cela signifie inviter les gens à un chat vidéo, même juste pour parler ou organiser un apéritif virtuel où tout le monde peut avoir un moment de partage à distance. L'inconvénient des projets virtuels est que vous devez apporter les formalités lors des réunions informelles. Téléchargez votre modèle de document personnalisable PRINCE2 2017 Approche de gestion de la communication? Ce document très utile, disponible au format Word, vous aidera dans la réalisation de votre projet PRINCE2 !

Stijn Janssens

Stijn est un consultant expert en gestion de projet, programme, portefeuille depuis plus de 12 ans.  Il est formateur et coach sur les Bonnes Pratiques et est certifié PMP®, PRINCE2®, MSP®, MOP®, P3O®, ITIL V3 et Lean IT. Retrouvez Stijn sur Linkedin  

Utiliser une méthode de gestion de projet signifie avoir des principes directeurs et des processus qui nous aident à gérer des projets. Le choix de la méthode est une décision essentielle: elle détermine votre façon de travailler et de communiquer avec votre équipe. Nous recevons souvent des questions sur l’utilisation d’AgilePM : quand puis-je utiliser la méthode AgilePM, pour quels projets? Généralement, le type de projet vous aide à choisir votre méthode. Voyons ensemble quelques-unes des caractéristiques des projets qui peuvent être gérés avec des méthodes Agiles:

• vous devez livrer un produit de qualité dans un délai préétabl,
• vous ne connaissez pas toutes les caractéristiques du produit final dès le début,
• les exigences devraient changer ou évoluer,
• des changements fréquents sont nécessaires,
• vous souhaitez tirer profit de certains bénéfices du projet avant la clôture du projet,
• le produit à produire peut générer de la valeur pour l’entreprise de manière incrémentale,
• votre environnement de travail est en constante évolution.

 

4 choses à savoir avant d’utiliser Agile Project Management - AgilePM

AgilePM est la seule méthodologie Agile qui se concentre sur la gestion de projet. Cela peut donc être le bon compromis si vous souhaitez utiliser une méthode de gestion de projet tout en mettant en pratique des principes agiles. Mais votre équipe est-elle prête à utiliser AgilePM comme méthode de gestion d’un projet? Voici 4 points clés de l’adoption de la méthode:

• La vision Métier guidant le projet est clairement spécifiée et comprise par tous les membres de l’équipe projet.

S’il n’y a pas de compréhension claire et partagée de la vision, il y a un risque d’utiliser le temps pour des détails de peu de valeur. Agile Business Consortium suggère une question à se poser pour comprendre si l’activité que nous faisons est alignée avec la vision : « Cette décision permet-elle de progresser dans le sens de la vision métier? »  

• Tous les participants au projet comprennent et acceptent que la livraison d’une solution acceptable et respectant les délais est la principale mesure de succès du projet.

Dans un projet Agile, tout le monde se concentre sur les moteurs d’activité et la livraison à temps. La recherche de la perfection est déconseillée.  

• Tous les membres de l’équipe projet acceptent que les exigences soient définies seulement à un haut niveau dans les premières phases du projet et que les détails émergeront durant la progression des développements.

Définir les exigences en détail dans les phases initiales du projet est risqué et pourrait être inexact – cela ne permet pas à la solution d’évoluer et nécessite un « contrôle du changement ». Il est donc important que l’équipe sache POURQUOI cette solution est importante. Assurez-vous donc que les exigences capturent les besoins de l’entreprise et ne sont pas une solution prédéfinie.  

• Tous les membres de l’équipe projet acceptent que des changements dans les exigences sont inévitables et que c’est uniquement en « embrassant ces changements » que la bonne solution émergera.

L’équipe de développement doit accepter le changement afin de fournir une solution optimale. Les changements nécessaires doivent avoir la priorité sur les travaux prévus.  

Pourquoi est-il essentiel de connaître ces points clés?

Un projet Agile est considéré comme réussi s’il respecte les contraintes de temps et de qualité. Il est donc important que l’équipe projet soit alignée sur les critères rapportés dans le questionnaire d’approche projet (PAQ) de l’Agile Business Consortium. Il s’agit d’un questionnaire (comprenant 17 affirmations) basé sur les facteurs clés de succès pour aider à mettre en évidence des risques potentiels pouvant affecter le succès du projet. Les réponses au PAQ ont un impact sur la gestion du projet. Le PAQ peut vous aider à connaître immédiatement les risques liés au choix d’une méthode Agile et aussi à la réussite du projet plus généralement.