Soutenance mémoire
Les méthodologies de gestion de projets traditionnelles
Introduction
Cette thèse étant sur le sujet de la gestion de projet, je pense qu’il est nécessaire, avant de rentrer dans l’explication d’autres notions, de s’accorder sur la définition même d’un projet. Un projet est une suite d’activités qui sont uniques, complexes et interconnectées. De plus, il a un commencement, une fin et est réalisé afin d’obtenir un produit unique, un service ou un autre résultat. Chaque projet est réalisé dans un cadre et un environnement de travail toujours changeant ce qui rend chaque activité et donc chaque projet unique. En prenant l’exemple d’un même projet réalisé en interne dans une entreprise année après année, l’équipe qui réalise ce dernier peut changer, le budget alloué peut être modifié et la période de réalisation peut être différente. Ce ne sont là que quelques variables, il en existe réellement une quasi-infinité ce qui rend chaque projet au moins très légèrement différent d’un autre.
De plus, les activités se doivent d’être complexes dans le sens qu’elles doivent représenter la recherche d’une solution et non simplement décrire une action répétitive. Pour prendre un exemple trivial, tondre la pelouse décrit une action simple alors que créer une structure de représentation de données décrit une suite d’activités complexes menant à une solution. Enfin, les activités se doivent d’être interconnectées d’une certaine manière. Cette interconnexion, une fois visualisée d’une manière holistique, représente une séquence logique d’activités. Par exemple, il est nécessaire de réaliser l’interface graphique d’une application avant de pouvoir implémenter le code réalisant son comportement. En plus de tout cela, un projet se doit d’avoir un but à atteindre en fonction de paramètres tels qu’un budget imposé, une limite de temps ou un environnement de travail défini pour ne citer que quelques exemples.
Méthodologies de gestion de projets
Qu’est-ce qu’une méthodologie de gestion de projets ?
Une méthodologie de gestion de projets est simplement un modèle d’organisation ayant pour but la réalisation avec succès d’un projet. Afin de parvenir à ce but, chaque méthodologie propose différentes règles, bonnes pratiques à suivre ainsi que d’autres outils qui auront pour but de pouvoir répondre à ces questions :Comment savoir ce qu’il est nécessaire de faire? Comment savoir ce qui va être fait? Comment le travail sera effectué ? Comment savoir que le travail a bien été réalisé ?
Comment pouvoir mesurer la réussite du projet ? Chacune des réponses à ces questions est essentielle afin de pouvoir s’assurer de bien connaître les actions à réaliser, le but du projet ainsi que pour s’assurer de sa réussite. Les méthodologies n’étant que des modèles, il est possible et même fréquent pour les entreprises de ne prendre que certaines parties ou certaines valeurs-clés de ces différentes méthodologies et de créer un modèle hybride et personnalisé afin de s’adapter au mieux soit aux types de projets réalisés par cette dernière soit au fonctionnement de l’entreprise. Toutes les méthodologies de gestion de projets mentionnés dans cette thèse sont construites selon les cinq groupes de processus de management tels que décrits dans le Project Management Body Of Knowledge (PMBOK) qui est un standard reconnu internationalement et qui regroupe les bonnes pratiques ainsi que les fondamentaux de la gestion de projet. Le PMBOK a été publié pour la première fois en 1987 puis a été modifié à quatre reprises par le Project Management Institute (PMI). Ce standard définit les 5 grands groupes de processus suivants : Démarrage, Planification, Exécution, Surveillance et Clôture.
Les différents types de méthodologies de gestion de projets
Selon Robert K. Wysocki, il existe quatre grandes catégories de méthodologies de gestion de projets (PMLC). Pour commencer, les méthodes traditionnelles (TPM) qui sont utilisées lorsque le but ainsi que la solution du projet à fournir sont clairement connues. Les projets utilisant ces méthodologies sont généralement relativement simples, communs et pour lesquels aucun ou extrêmement peu de changements sont attendus tout au long de la période de réalisation du projet. Ensuite viennent les méthodologies agiles de gestion de projets (APM). Ces méthodologies, plus récentes, sont utilisées lorsque le but est clairement connu mais la solution pour atteindre ce but ne l’est pas. Les méthodologies agiles permettent, entre autres, de mieux pouvoir répondre aux risques découlant de la réalisation de ce type de projets. Ces méthodologies sont utilisées idéalement lors du développement d’un projet complexe et/ou dans un environnement incertain. Le troisième groupe comprend les méthodologies de gestion de projets dits « extrêmes » (xPM). Ces méthodologies sont utilisées afin de réaliser des projets dont ni le but à atteindre, ni la solution pour y parvenir ne peuvent être clairement définis. C’est typiquement le cas des projets de recherche et développement de grandes entreprises ou de grandes institutions. Ces projets sont hautement risqués mais permettent aux compagnies les réalisant d’obtenir un avantage considérable sur leurs concurrents. Enfin, les méthodologies de gestion de projets « Emertxe » (Extrême à l’envers) (MPx) permettent de réaliser au mieux les projets dont la solution est connue mais pas le but de cette solution. Ces projets sont assez rares mais peuvent par exemple consister en la découverte d’une nouvelle technologie sans pour autant avoir en tête une utilisation précise de celle-ci. La réalité virtuelle est un exemple de technologie récente dont une entreprise pourrait vouloir explorer les possibilités sans savoir si elle l’utilisera réellement dans le futur.
Les méthodologies de gestion de projets traditionnelles
Les méthodologies de gestion de projets traditionnelles peuvent encore être séparées en deux sous-catégories : linéaires et incrémentales. Les méthodologies traditionnelles linaires sont utilisées lorsque les informations sur le but du projet ainsi que sa solution sont connues presque à la perfection. Les méthodologies traditionnelles incrémentales sont utilisées lorsque les informations ne sont pas connues à la perfection mais malgré tout suffisamment pour justifier le choix d’une méthodologie traditionnelle au lieu d’une méthodologie agile. Encore une fois, le choix de la méthodologie à utiliser est le résultat d’une décision n’ayant pas qu’une bonne réponse.
Ensuite, il est évident que ce type de projet ne nécessite pas que les membres de l’équipe le réalisant soient les plus compétents. En effet, ces projets étant souvent des répétitions de projets déjà réalisés, il est possible de réutiliser des modèles existants, de documents par exemple, et même de se référer à des expériences tirées de la réalisation ces projets.
Finalement, les équipes réalisant ce type de projet n’ont pas besoin de tous se trouver au même endroit. Les étapes étant déjà connues et les changements étant extrêmement improbables, (c’est pour cela que ce type de méthode est choisie) ce type de projet est le plus simple à réaliser avec une équipe dispersée géographiquement. Évidemment, il existe également plusieurs désavantages à utiliser cette catégorie de méthodologie. Le plus évident est que chaque changement est extrêmement difficile à inclure dans ce type de modèle. Le projet étant planifié et les tâches étant réparties dès le début, chaque changement représente le risque de devoir modifier l’ensemble de la planification. Cela risque de coûter beaucoup de temps et donc d’argent. Pour continuer sur le coût des projets utilisant ces méthodologies, le projet a été planifié pour être réalisé au mieux en fonction du temps et de l’argent convenu avec le client. Le problème est que ce dernier ne recevra le produit qu’à la fin du projet et ne pourra juger de la qualité du produit fini qu’une fois le projet achevé. Si le client devait avoir des modifications à effectuer sur le produit final, le budget aurait déjà été dépensé et il ne resterait donc plus d’argent pour pouvoir effectuer les changements désirés par le client. Un autre désavantage est que ce type de projet nécessite une planification complète dès le début du projet, ce qui peut se révéler être une dépense de temps inutile. Lors de la réalisation d’un projet informatique, il est virtuellement impossible qu’aucun changement ou événement imprévu ne se produise. Par exemple, si un employé venait à tomber malade ou s’il était réaffecté à une autre équipe réalisant un autre projet étant prioritaire, il serait nécessaire de redistribuer les tâches effectuées par cet employé aux autres membres de l’équipe et de replanifier l’ensemble du projet. Dans ce cas de figure, la planification complète qui aurait été réalisée au début du projet deviendrait complètement inutile.
Les méthodologies incrémentales possèdent également leur lot de points négatifs. Par exemple, comme pour les méthodologies linéaires, la séquence des activités se doit d’être rigoureusement définie dès le commencement du projet, ce qui veut dire qu’après la partie initiale de planification, aucun changement ne devrait survenir. Il est possible durant cette phase de prioriser les activités en fonction de différents critères comme par exemple par risque, par disponibilité des ressources nécessaires à l’accomplissement de la tâche ou encore par valeur pour le client. Une fois l’ordre décidé, il ne devrait plus être changé par soucis de cohérence. Il est nécessaire de se rappeler que ce type de méthodologies a été sélectionné car il a été estimé que le risque de changement se produisant durant le projet était extrêmement faible. Si, malgré tout, cette éventualité venait à se présenter, les méthodologies incrémentales ne pourraient pas répondre d’une manière aussi satisfaisante à ce besoin d’adaptation que le feraient les méthodologies qui seront le sujet de la prochaine partie de ce chapitre. De plus, l’attribution de toutes les activités aux différents incréments en prenant en compte toutes les dépendances peut se révéler être un travail long et compliqué, ce qui le rend coûteux tant au niveau temporel qu’au niveau financier. L’attribution des activités aux différents incréments n’est pas la seule activité consommant beaucoup de temps et rallongeant la période nécessaire à l’accomplissement d’un projet avec une méthodologie incrémentale comparé à une méthodologie linéaire. Une autre de ces activités qui peut se révéler coûteuse en temps est l’intégration régulière chez le client. Cette dernière est une force des méthodologies incrémentales sur les méthodologies linéaires car elle apporte une réelle plus-value au client mais elle représente également une faiblesse étant donné que cette intégration rallonge le temps de développement.
Les méthodologies agiles itératives
Les méthodologies itératives sont utilisées lorsque l’entièreté de la solution n’est pas connue mais pas uniquement. Elles servent également lorsqu’une méthodologie incrémentale aurait pu être utilisée mais les risques de changements ont été jugés trop importants pour utiliser une méthodologie incrémentale. Finalement, elles sont utilisées lorsqu’une méthodologie adaptative aurait pu être employée mais des doutes sont exprimés quant à l’implication du client. Ce dernier point sera discuté plus en détail notamment dans le chapitre sur les méthodologies adaptatives. Une autre caractéristique intéressante des méthodologie agiles est qu’elles n’ont en général pas de date de fin prévue dès le début du projet. En effet, la fermeture d’un projet agile est fréquemment décidée lorsque le nombre de fonctionnalités implémentées sont suffisantes pour satisfaire le client ou lorsque le budget attribué au projet a été utilisé entièrement.
Comme pour la méthode précédente, nous pouvons voir que les méthodologies agiles itératives fonctionnent en une séquence d’activités qui se répète. La différence avec les méthodologies traditionnelles est qu’ici, une boucle est faite pour revenir à la phase de planification d’une itération après la fermeture de la précédente. C’est ici, comme nous pourrons le voir plus bas, que réside toute la force des méthodologies agiles. Durant chaque itération est produite une partie de la solution telle qu’elle est sûre d’être connue au moment de la planification et étant celle ayant le plus de valeur pour le client. Toutes les versions intermédiaires produites à la fin de chaque itération se doivent d’être prêtes à être implémentées et utilisées dans l’environnement du client. Comme mentionné dans la partie d’introduction sur les méthodologies agiles, elles ne sont délivrées que si elles ont été prévues ainsi ou à la demande du client. Les méthodologies agiles étant légèrement moins instinctives que les méthodologies traditionnelles, je vais détailler les trois phases les plus différentes comparé à ces dernières.
Un des grands avantages des méthodologies adaptatives est qu’elles ne gaspillent pas de temps en planning détaillé d’un futur incertain tout en gardant l’aspect itératif des phases et la capacité d’adaptation aux changements qui en découlent. Cet aspect itératif est basé sur le même principe que lors de l’utilisation de méthodologies itératives, ce qui assure une valeur aussi grande que possible pour le client quel que soit l’avancement du projet. Chaque cycle apprenant des erreurs des cycles précédents, les méthodologies adaptatives sont donc basées un maximum sur l’apprentissage. De plus, elles mettent l’emphase sur la découverte de la solution ainsi que sur l’adaptation aux changements ce qui rend ce type de projet en général plus risqué que lors d’utilisation de méthodologies incrémentales. La solution étant presque inconnue au commencement du projet, le déroulement d’un projet avec des méthodologies adaptatives peut être visualisé comme une avance à tâtonnement. Si aucune solution n’est trouvée après l’exploration d’une direction, la recherche de la solution est redirigée dans une nouvelle direction tout en espérant qu’une solution convenable puisse être découverte rapidement. Étant donné la nature incertaine de ces projets, un minimum de planification est réalisé et l’énergie de toute l’équipe est concentrée sur la découverte de la solution plutôt que sur la création d’une documentation formelle exhaustive. Les communications formelles sont d’ailleurs réduites autant que possible en favorisant au maximum les échanges informels entre les différents acteurs du projet.
Planification du cycle
Durant cette phase, le planning du cycle est effectué, si possible en fonction du plan de haut niveau réalisé durant la phase de détermination de la vision si celui-ci a été produit. Ensuite, les fonctionnalités qui ont été découvertes et évaluées comme étant les plus prioritaires sont sélectionnées et disposées d’une manière détaillée dans le cycle.
Contrôle et vérification du cycle
Durant cette phase, comme pour les méthodologies itératives, toutes les fonctionnalités nécessaires découvertes par l’équipe ainsi que tous les changements seront ajoutés au document créé à cet effet. Tous ces éléments seront ensuite placés dans une liste de priorités et considérés durant la prochaine phase de planification de phase. La formalité des méthodologies itératives est changée en communications informelles ce qui permet une plus grande créativité de la part de tous les membres de l’équipe. Malgré l’emphase importante portée sur l’informalité des communications, il peut être bénéfique de garder un historique de différentes métriques tels que l’évolution de la performance de l’équipe ou le nombre de changements apparus ainsi que leur impact qui auront été récoltés par des moyens plus formels tels que des rapports. Une des métriques pouvant se montrer être le plus utile pour contrôler l’avancement du projet ainsi que l’implication du client est celle de l’évolution de la taille du document contenant les fonctionnalités découvertes ainsi que les changements mentionnés plus haut. Celui-ci contiendra toutes les découvertes de l’équipe ainsi que tous les changements. L’évolution de la taille de ce document peut servir à s’assurer d’être sur la bonne voie
Premièrement, une méthodologie traditionnelle est utilisée lorsque aucun changement ne devrait apparaître alors qu’une méthodologie agile est utilisée lorsque les changements sont anticipés. Par conséquent, les méthodologies traditionnelles doivent utiliser une gestion formelle du changement qui n’est gérée que par le responsable de projet ce qui rend la supervision de l’équipe nécessaire. Les équipes réalisant un projet avec des méthodologies agiles, elles, n’ont pas besoin de supervision vu que le changement est prévu à chaque fin d’itération. Ensuite, la durée de chaque activité étant déjà connue pour les équipes réalisant un projet avec une méthodologie traditionnelle, grâce aux précédents projets similaires ayant déjà été réalisés, la planification peut être faite d’une manière très précise pour un grand nombre de personnes. En revanche les méthodologies agiles nécessitant une planification au début de chaque itération et pour des tâches n’ayant pas été réalisées par le passé, il est impossible de connaître avec précision leurs durées et par conséquent nécessite une communication entre les membres de l’équipe qui peut se trouver être trop longue dans une équipe trop grande. En ce qui concerne l’expérience ainsi que les compétences nécessaires pour les membres de l’équipe, il est évident qu’un projet ayant déjà été effectué quasiment à l’identique dans le passé peut fournir de nombreuses réponses et solutions aux problèmes qu’il est possible de rencontrer, ce qui ne nécessite pas de compétences particulières. En revanche, les projets agiles nécessitent de nouvelles réponses à de nouveaux problèmes, ce qui augmente le niveau de difficulté et donc le niveau de compétence requis. De plus, pour les projets utilisant des méthodologies traditionnelles, il est possible de réutiliser des modèles existants, ce qui diminue encore la difficulté du projet.
Finalement, la distribution de l’équipe est une caractéristique beaucoup moins stricte que les autres. L’idéal pour réaliser un projet serait une équipe réduite de professionnels extrêmement compétents qui ne travailleraient que sur le projet concerné et qui se trouveraient au même endroit géographique. Malheureusement dans la pratique il est rarement possible de pouvoir travailler dans de telles conditions. Par conséquent, même s’il est plus simple au niveau de la gestion d’une équipe et surtout plus rapide de pouvoir discuter directement et immédiatement entre les membres, grâce à la technologie actuelle il est tout de même possible de travailler avec une équipe géographiquement dispersée assez aisément. Ce point sera le sujet central de la partie consacrée à la gestion de projet dans une équipe multiculturelle qui sera discuté en détails plus bas.
Conclusion
Malgré ces facteurs, le choix de la bonne méthodologie à employer dépend également grandement de la personne responsable de sa réalisation et le choix final est toujours subjectif. Il n’existe donc pas une seule bonne réponse mais des avantages et des inconvénients à l’usage de chaque méthodologie que le responsable de projet se doit d’évaluer avant de prendre une décision. De plus, il est très rare qu’une seule méthodologie soit utilisée tout au long du projet. Selon un rapport de Forrester intitulée « The 2015 State Of Agile Development : Learn From Agile Expert Firms » (L’état du développement agile en 2015 : Apprendre des compagnies expertes de l’agile) 47% des grandes entreprises sondées effectuent leurs projets en utilisant une méthode Waterfall, qui est une méthodologie linéaire, pour la partie initiale puis changent pour une méthodologie agile telle que Scrum durant le développement et finissent par reprendre une méthodologie linéaire pour la partie finale du projet.
Exemple : Scrum
La méthodologie Scrum est relativement populaire parmi les méthodologies agiles. Ses itérations, appelées sprints, sont de durée fixe. La raison pour cela est simple. Avec une durée de sprint variable, si, à la fin d’un sprint, un développeur a du retard sur la tâche qu’il était supposé terminer, il est possible de simplement rallonger la durée du sprint, action qui est prévue par la méthodologie. Avec une durée fixe, le travail à effectuer aura été choisi et évalué afin que sa durée ne dépasse pas la date de fin du sprint. Par conséquent, avec une durée fixe, ces sprints motivent l’équipe à finir le travail attribué dans les temps.
Le travail à effectuer est représenté par des stories. Ces dernières peuvent être considérées comme un rappel d’une exigence du client. Elles peuvent être accompagnées de documents supplémentaires si cela a été considéré comme nécessaire. Les stories se présentent toujours sous la même forme : « En tant que … je veux … afin de … ». Toutes les stories devraient respecter le modèle « Invest ».
Il existe trois rôles dans la méthodologie Scrum. Le product owner est le représentant du client. Son rôle est d’expliquer les spécifications à l’équipe, de valider le rendu, de décider de la priorité de chaque story et de conserver la liste de ces stories, appelé product backlog, à jour. Le Scrum master est responsable de s’assurer que le processus est mis en place correctement et que l’équipe le respecte. De plus, il a le rôle de facilitateur pour l’équipe et a donc le devoir de s’assurer que les autres membres de l’équipe ne soient pas dérangés par exemple par des problèmes administratifs ou de réseau. Enfin, les membres de l’équipe sont responsables de réaliser le travail à effectuer. À mesure que le projet avance, le rôle du Scrum master diminuera étant donné que l’équipe sera de plus en plus habituée à travailler ensemble et à respecter la méthodologie alors que le rôle du product owner augmentera étant donné qu’il est responsable de la tenue des différentes métriques ainsi que de la mise à jour du document recensant toutes les stories et dont la taille augmente avec le temps. À l’exception du premier sprint, appelé le sprint 0, durant lequel la détermination de la vision est effectuée (voir figure 4), tous les sprints sont constitués de la même manière c’est-à-dire avec la planification du cycle, son lancement, le contrôle et la vérification de l’avancement du travail puis, pour finir, la fermeture du cycle. Au début du sprint (planification et lancement du cycle sur la figure 4) durant une réunion appelée sprint planning, le travail à réaliser durant le sprint est déterminé. Premièrement, les stories contenues dans le product backlog ayant le plus de valeur pour le projet sont rajoutées au sprint backlog, document recensant les stories à effectuer durant le sprint. Les stories sont ajoutées au sprint backlog jusqu’à ce que la durée combinée de toutes les stories sélectionnées soient égales à la durée totale du sprint.
Cet adage, appelé la loi de Conway (1967), est considéré comme une observation sociologique valide qui souligne l’importance pour les entreprises réalisant des systèmes, notamment informatiques, de créer et d’entretenir des structures de communication adaptées qui sont vitales pour la réalisation de projets. La gestion des membres d’une équipe ainsi que de leurs communications sont des tâches essentielles à tout projet et qui sont représentées respectivement par le domaine de compétence en gestion de projets ainsi qu’en gestion des communications dans le PMBOK. L’importance et la difficulté de ces tâches se retrouvent décuplées lors de la gestion d’une équipe géographiquement distribuée. Dans ce chapitre, nous commencerons par observer les différences entre les équipes dont les membres sont situés à proximité et celles dont les membres sont éloignés. Ensuite, nous verrons les avantages de ces équipes et finirons par décrire les éléments nécessaires afin de réussir les projets confiés à ce type d’équipe.
Différences entre équipes locales, distribuées et internationales
Dans cette thèse nous allons différencier trois types d’équipes. Premièrement, les équipes locales qui sont celles dont tous les membres sont situés au même endroit géographique et qui sont capables d’un contact direct quasi-immédiatement. Ensuite, les équipes distribuées qui sont celles dont les membres sont suffisamment éloignés géographiquement pour ne pas pouvoir communiquer quasi-immédiatement face-àface. Par exemple, une équipe dont les membres travaillent de chez eux ou dans des bureaux différents dans le même pays est considérée comme une équipe distribuée. Enfin, les équipes internationales sont des équipes distribuées et devant faire face à diverses difficultés liées à la séparation géographique dont nous parlerons à plusieurs reprises à travers tout le chapitre. Tout au long de ce dernier, nous allons voir quelques exemples, parmi beaucoup d’autres, des différences existantes entre ces trois types d’équipes.
Comment faire fonctionner une équipe internationale ?
Les équipes internationales ont des propriétés et des risques supplémentaires comparés aux équipes locales et nécessitent donc une gestion différente. Nous allons voir ici les quatre domaines auxquels il faut accorder une attention particulière. Premièrement, tout projet nécessitant des personnes pour les réaliser, il est nécessaire de pouvoir gérer une équipe ainsi que l’organisation de ses membres d’une manière adaptée. Nous allons donc voir certains des facteurs ayant une influence importante sur la gestion des ressources humaines d’une équipe internationale. Ensuite, lors de la phase de planification du projet, il existe également des spécificités auxquelles il est important de porter une attention particulière. Ces dernières seront abordées dans la deuxième partie de ce chapitre. Une autre partie vitale de tout projet, et encore plus lors de l’utilisation de méthodologies agiles comme nous l’avons vu précédemment, est la communication entre les membres de l’équipe. Nous allons donc discuter de la manière de s’assurer que la communication soit optimale malgré la distance entre les membres. Pour finir, afin de faciliter la communication et la collaboration entre les membres de l’équipe il est nécessaire d’utiliser des outils. Ce sont eux qui seront le sujet central de la fin de cette partie.
La gestion des ressources humaines
Premièrement, il est essentiel pour les équipes globales que les membres de l’équipe, spécialement ceux ayant des postes de responsables, soient conscients des différences culturelles présentes entre les membres de l’équipe et sachent comment créer un environnement de travail dans lequel tous soient confortables. En plus des différences culturelles, les responsables doivent être capables de discerner les différentes personnalités de ces personnes et en tenir compte lors des prises de décisions. Ensuite, afin de simplifier la communication ainsi que son efficacité, il est conseillé de mettre en place dès le début du projet une structure hiérarchique claire. Il est évidemment bénéfique de faire cela dans tous les types de projets mais dans le cadre d’un projet ayant une dimension internationale, une hiérarchie claire permet de fluidifier et de rendre plus rapide les communications tout en réduisant la probabilité de survenance de certains risques comme par exemple l’apparition de tensions au sein de l’équipe à cause d’un conflit. Cela nous amène donc à aborder un troisième point d’importance : la dynamique de l’équipe. Il est essentiel de discerner les termes de communication et de collaboration entre les membres d’une équipe. Bien que la communication entre les membres soit importante, le but est une réelle collaboration entre ces derniers et afin de pouvoir atteindre ce but, il est entre-autre nécessaire qu’il existe un climat prospère dans lequel chacun a la possibilité de s’exprimer et où, si possible, règne une certaine confiance entre les membres. Afin de mettre en place cet environnement, il est conseillé de regrouper en un même endroit géographique les membres de l’équipe avant le début du projet et aussi régulièrement que jugé nécessaire.
La gestion de la planification
Les différences de fuseaux horaires ont déjà été mentionnées à plusieurs reprises. Leur gestion est essentielle lors de la réalisation d’un projet avec une équipe dispersée sur le globe. Grâce à elle, il est théoriquement possible de progresser dans l’avancement d’un projet 24 heures sur 24. D’un autre côté, les heures de travail se chevauchant entre les localisations étant réduites, la collaboration entre les deux équipes s’en retrouvera forcément détériorée.
Afin de gérer correctement les différences d’heures dues aux fuseaux horaires dans lesquels les différents membres se trouvent, il est conseillé de créer des plannings prenant en compte ce problème. Cela peut être fait, par exemple, en fournissant à chaque employé une table de conversion des heures ou, si cela est possible, de créer une petite application affichant l’heure du jour de chaque membre en temps réel. Cette gestion de la planification est également vitale lors des phases nécessitant une plus grande collaboration entre les équipes. Durant ces dernières, il est nécessaire de prévoir des plages horaires durant lesquelles tous les membres pourraient travailler en même temps. Ce cas de figure apparaît notamment lorsque des réunions pour lesquelles la présence de tous les membres de l’équipe est requise. La planification doit également être faite afin de prendre en compte les activités partageant des dépendances. Par exemple, lors du développement d’une interface utilisateur par deux équipes se partageant les différentes fenêtres de l’application, il est nécessaire de penser à l’enchainement de ces dernières avant de pouvoir les attribuer à une certaine équipe. De plus, afin de faciliter le travail avec des collègues éloignés géographiquement, il peut être nécessaire d’adapter les heures de travail de certaines équipes. Les changements d’horaires ne sont généralement pas bien accueillis, par conséquent il est bon de s’assurer du besoin impératif de mettre en place ces changements. De plus, la collaboration plus importante entre les équipes n’étant pas forcément nécessaire durant toute la durée du projet, le mieux est de limiter la durée de ces modifications d’horaire. De même, des changements importants pour une seule équipe ne sont pas conseillés, il vaut mieux à la place changer de quelques heures seulement les horaires des équipes pour lesquelles les changements sont absolument nécessaires. Afin d’obtenir une équipe performante, il est également vital de s’assurer de ne pas surcharger l’équipe de travail, notamment durant des heures inhabituelles ; le fait de travailler plus ne correspondant pas toujours avec le fait d’être plus productif.
En plus de la gestion des fuseaux horaires, il est nécessaire de planifier une vision claire du projet afin de s’assurer que les membres de l’équipes comprennent clairement les buts ainsi que les nécessités du projet, tant au niveau des demandes formelles du client, en termes de fonctionnalités par exemple, que les demandes non formulées telles que les qualités non fonctionnelles (QNF). Les QNF servent à déterminer comment le système est censé être plutôt que ce qu’il est censé faire. Afin de s’assurer de fournir une solution dont le client sera satisfait, il est nécessaire d’être extrêmement attentif aux QNF. Ces dernières peuvent être de différents types. Par exemple, il existe des QNF concernant l’accessibilité du système, sa disponibilité, sa sécurité, sa fiabilité, sa robustesse, etc. Pour prendre un exemple, considérerons la disponibilité du système. Si lors d’un rendez-vous avec le client celui-ci nous dit que le système doit être disponible, il est nécessaire de se renseigner en termes précis et mesurables sur la signification d’un système disponible pour le client. Ces questions modifient complètement la structure du système ainsi que les moyens, notamment financiers, nécessaires. Par exemple, un système critique à l’entreprise qui doit absolument être disponible tous les jours et 24 heures sur 24, comme le système de réservation d’une compagnie aérienne, nécessitera de la redondance dans la quasi-totalité des systèmes et donc multipliera le coût du projet. Afin de fournir une solution satisfaisante au client, il est nécessaire de s’assurer que les QNF soient identifiées et implémentées correctement. Bien que cela devrait être fait dans tous les projets, le fait de travailler avec une équipe internationale peut poser le problème supplémentaire de l’interprétation. Afin de palier à ce risque, la création d’un document de vision contenant toutes les QNF ainsi que leur description en termes précis et mesurables ainsi que la communication de ce document à tous les membres de l’équipe, dans autant de langues que possible, devient une nécessité absolue.
Les outils
La collaboration entre des équipes très éloignées géographiquement a été initialement rendu viable par le développement des moyens de communication, tels que le téléphone, qui ont permis à deux personnes de communiquer quasi-instantanément malgré une grande distance les séparant. Cette collaboration a ensuite été améliorée par l’utilisation d’internet et des différents moyens de communication rendus possibles tels que les emails, l’échange d’images, le partage d’écran en temps réel et la communication audio et vidéo. Il existe également des moyens de partage de fichiers, de calendriers ainsi que de messages instantanés. Selon l’étude de Forrester « Best practices : Five Strategies For Leading Diverse, Distributed Teams To Success », (Les meilleures pratiques : cinq stratégies pour guider les équipes diversifiées et distribuées au succès) 94% des personnes consultées utilisaient au moins une fois par semaine des emails pour communiquer avec leurs collègues et 71% utilisaient un calendrier électronique tel que celui proposé dans Microsoft Outlook. Selon la même enquête, 28% utilisaient un système de messagerie électronique, 24% partageaient des documents grâce à des systèmes tels que SharePoint et 14% utilisaient un système de Web conférence. La détermination des outils utiles à l’équipe dépend principalement de six facteurs. La nature des interactions entre les membres de l’équipe, la nécessité que le message soit remis à son destinataire d’une manière quasi-instantanée, le nombre de destinataires de l’information, le coût lié à l’utilisation du moyen de communication, l’environnement dans lequel l’outil viendrait s’installer ainsi que si l’outil sera réellement utilisé par les membres de l’équipe.
La planification des risques
La première phase a pour objectif l’obtention d’un engagement sérieux de la part de toutes les parties-prenantes au projet. Cet engagement se doit de confirmer que chacun participera et se conformera au processus de gestion des risques. Ce dernier comprend notamment l’identification des risques, leur analyse ainsi que leur traitement. De plus, cet engagement permet de s’assurer que le travail réalisé durant ce processus soit disponible pour tous et que les mesures jugées nécessaires soient misent en place à temps. Finalement, cet engagement permet de s’assurer que toutes les ressources nécessaires à la gestion des risques, en termes de temps et de technologie par exemple, seront bien à disposition. En outre, la phase de planification sert de préparation des ressources, des processus ainsi que des outils disponibles afin de pouvoir organiser les activités représentées par les phases suivantes du cycle de vie de la gestion des risques.
L’identification des risques
Cette phase peut commencer dès que l’engagement de toutes les parties-prenantes au projet a été obtenu et que les activités ont été planifiées. Afin de pouvoir traiter les risques, il est nécessaire d’être capable de les identifier à l’avance et de les réunir sous forme de liste. Comme la définition d’un risque nous l’a appris, il est nécessaire de lister autant les risques positifs (opportunités) que les risques négatifs (menaces). En plus des risques, il est essentiel pour chacun de définir leurs causes ainsi que leurs répercussions tout en étant vigilant à bien identifier les réels problèmes et non pas uniquement leurs symptômes. Par exemple, un manque de motivation au sein de l’équipe est un symptôme pouvant par exemple être causé par une trop grande pression sur l’équipe. Ce travail d’identification est encore compliqué par le fait que les risques sont rarement isolés et peuvent impacter le projet de différentes façons durant tout le cycle de vie du projet.
Au centre, nous trouvons la valeur attendue du projet pour l’organisation qui est bien évidemment impactée par chaque risque. Le deuxième cercle est composé de domaines-clé au déroulement du projet, bien qu’insuffisantes pour garantir la réussite d’un projet, elles sont essentielles dans tout type de projet. En troisième, le domaine d’où provient le risque. Ensuite, la quatrième catégorie sépare les risques en internes ou externes. Les risques étant de la responsabilité du chef de projet, des employés pas assez formés, par exemple, sont classés dans la partie « interne ». La cinquième couche représente la connaissance du risque. Les risques connus sont les risques considérés comme certains de se produire. Les risques inconnus-connus sont les risques qui ont pu être identifiés mais sans certitude qu’ils se réaliseront. Les risques inconnus-inconnus sont les risques résiduels ainsi que les événements considérés comme extrêmement improbables. La sixième et dernière couche représente la phase de développement du projet durant laquelle le risque a des chances de se réaliser. N’étant qu’un modèle, il est bien entendu possible de changer ce Framework et de lui rajouter des catégories qui seraient utiles pour un projet spécifique.
L’analyse et l’évaluation des risques
La phase d’analyse commence une fois que tous les risques sont considérés comme identifiés et que leurs causes et effets ont été compris. L’objectif de la phase est de connaître quels risques méritent d’être adressés. La réponse à cette question peut varier, notamment en fonction de la tolérance de l’entreprise et en termes de ressources disponibles, de budget ou de temps ainsi que de l’importance du projet. Afin de connaître ces risques, il est nécessaire de pouvoir, pour chacun répondre à ces deux questions : Quelle est la probabilité que ce risque survienne ? Quelle est l’impact sur le projet si le risque survenait ? La réponse peut être trouvée de deux manières différentes. L’objectif de ces deux approches est de pouvoir prioriser au mieux les risques afin d’identifier ceux pour lesquels il est nécessaire de prendre des décisions. Premièrement, l’approche qualitative qui est subjective et se base sur l’analyse du risque par jugement et par expérience. Il existe de très nombreuses techniques d’analyse qualitative de risques. Parmi elles, le tableau de risque-impact consiste en un tableau de quatre colonnes. La première contient la description du risque, la deuxième un pourcentage de probabilité de survenance estimée du risque, la troisième un impact estimé sur le projet allant de zéro à dix et finalement, dans la dernière colonne, la valeur du risque qui est représentée par le produit de la probabilité et de l’impact du risque. La liste de tous les risques est ensuite priorisée par cette valeur estimée du risque. Une analyse qualitative est plus efficace si elle est réalisée avec autant de parties-prenantes représentées que possible afin d’obtenir différents points de vue sur un même risque.
Le traitement des risques
Comme pour l’identification des risques pour lesquels il a été jugé nécessaire de trouver une réponse, le choix de la stratégie de traitement des risques est dépendant de plusieurs facteurs. Premièrement, la nature du risque (ses propriétés telles qu’identifiées grâce au Framework ainsi que le déclencheur du risque sont des exemples d’éléments composant la nature d’un risque). Ensuite, l’impact et la probabilité de réalisation du risque tel que définis durant la phase précédente. Finalement, la tolérance au risque ainsi que les préférences des différentes parties prenantes. Un exemple pour ce dernier point peut être la préférence de la part d’un client d’un projet en retard plutôt qu’un projet délivré en temps et en heures mais plus cher qu’initialement prévu. Il existe quatre réponses possibles à un risque. Pour commencer, l’acceptation ou la non considération d’un risque peut être faite lorsque ce dernier est considéré comme suffisamment improbable ou ayant un impact suffisamment petit sur le projet pour être considéré comme quasi insignifiant. Si le risque est considéré comme extrêmement improbable mais a un impact énorme sur le projet, il est possible de s’en occuper soit en prévoyant des réserves suffisantes dans le budget afin de pouvoir répondre au risque soit en prévoyant un plan alternatif. C’est par exemple le cas pour les entreprises ayant un plan de reprise des activités en cas de désastre (DRP). La deuxième méthode est l’évitement complet du risque, c’est-à-dire trouver des moyens d’éviter que le risque ne se produise d’une manière active, par exemple en choisissant de ne pas réaliser la partie du projet durant laquelle le risque a des chances de se produire si cela est possible. Un autre exemple, si le risque de guerre civile dans le pays dans lequel se trouve l’entreprise est jugé comme important, il peut être décidé de la relocaliser complètement afin d’éviter complètement le risque identifié.
Il existe plusieurs manières de surveiller un risque. Premièrement, un audit peut être fait afin de s’assurer que tous les risques ont été correctement identifiés et analysés. De plus cet audit peut garantir que la mise en place des procédures de réponse qui ont été sélectionnées a été effectuée d’une manière satisfaisante et que ces procédures sont actualisées d’une manière régulière. Cet audit peut être réalisé par une équipe ou un manager qui devraient, à chaque fois que cela est possible, être externe au projet afin d’offrir une nouvelle perspective et d’éviter des tensions au sein de l’équipe. En plus d’audits ponctuels, l’équipe réalisant le projet doit fréquemment tenir des réunions de révision des risques. Cette réunion se concentrera sur l’identification de nouveaux risques et sur la mise à jour de l’évaluation des risques déjà identifiés. En plus de maintenir la liste des risques à jour, cette réunion permet de rappeler à tous les membres de l’équipe quels sont les risques pour lesquels il est nécessaire d’être spécialement vigilant et quels risques sont en train de devenir plus dangereux pour le projet.
Finalement, un système formel de communication, par l’envoi de rapports par exemple, similaire aux réunions de révision des risques peut être mis en place afin de pouvoir contrôler au mieux les risques
La réponse aux risques
La réponse aux risques est la dernière phase du cycle de vie d’un risque. Une fois que les métriques de déclenchement d’un risque ou que ses conditions de réalisation se sont présentées, il est nécessaire d’appliquer les actions appropriées rapidement afin d’éviter que le problème n’empire ou ne se propage à d’autres parties du projet. C’est à ce moment que l’identification de la nature ainsi que des liens entre les projets se montrent le plus utile. Normalement, les actions à entreprendre sont celles qui ont été identifiées dans le RRP durant la phase de traitement des risques. Les résultats des actions entreprises pour un risque particulier sont une source immense d’informations qui peuvent être utilisés comme leçons pour les risques des projets futurs. Les leçons tirées de ces décisions devraient être partagées au sein de l’entreprise afin de pouvoir être utiles à toutes les équipes et améliorer leur efficacité. La connaissance des issues provenant des décisions faites pour faire face à un risque permet d’améliorer le processus de gestion des risques dans son ensemble. De plus, avec suffisamment d’informations sur un risque, il est possible de comprendre pourquoi une certaine décision a été prise et de comprendre ses implications sur les autres risques. Finalement, grâce aux informations recueillies sur un risque, il est possible d’acquérir de l’expérience afin de mieux faire face à un risque si celui-ci venait à apparaître durant le déroulement d’un autre projet.
|
Table des matières
1. Introduction
2. Méthodologies de gestion de projets
2.1 Qu’est-ce qu’une méthodologie de gestion de projets ?
2.2 Les différents types de méthodologies de gestion de projets
2.2.1 Les méthodologies de gestion de projets traditionnelles
2.2.1.1 Les méthodologies traditionnelles linéaires
2.2.1.2 Les méthodologies traditionnelles incrémentales
2.2.2 Les méthodologies de gestion de projets agiles
2.2.2.1 Les méthodologies agiles itératives
2.2.2.1.1 Déterminer la vision
2.2.2.1.2 Planification de l’itération
2.2.2.1.3 Fermeture de l’itération
2.2.2.2 Les méthodologies agiles adaptatives
2.2.2.2.1 Déterminer la vision
2.2.2.2.2 Planification du cycle
2.2.2.2.3 Contrôle et vérification du cycle
2.2.2.2.4 Fermeture du cycle
2.3 Quand utiliser quel type de méthodologie ?
2.3.1 Par connaissance du but et de la solution
2.3.2 Par tolérance au changement
2.3.3 Conclusion
2.4 Exemple : Scrum
3. Gestion d’équipes internationales
3.1 Différences entre équipes locales, distribuées et internationales
3.2 Les avantages des équipes internationales
3.3 Comment faire fonctionner une équipe internationale ?
3.3.1 La gestion des ressources humaines
3.3.2 La gestion de la planification
3.3.3 La gestion des communications
3.3.4 Les outils
4. Gestion des risques
4.1 La planification des risques
4.2 L’identification des risques
4.3 L’analyse et l’évaluation des risques
4.4 Le traitement des risques
4.5 Le contrôle des risques
4.6 La réponse aux risques
5. Problèmes et avantages
5.1 Pression sur l’équipe
5.2 Les risques des méthodologies agiles et traditionnelles
5.3 L’importance de la vidéo dans les communications
6. Conclusion
Télécharger le rapport complet
