Introduction
Les projets sont souvent le moyen d’opérationnaliser les plans stratégiques d’une organisation. Des projets sont envisagés pour développer des produits et des services et gagner en efficacité opérationnelle. Les entreprises sont de plus en plus projetées et les dépenses mondiales en projets sont de l’ordre de plusieurs milliards de dollars par an (Williams, 2005). Les raisons sont évidentes. Les projets offrent l’occasion d’utiliser des pratiques de gestion de projet qui favorisent une utilisation efficiente et efficace des ressources. Cependant, malgré les progrès dans la discipline et la profession de gestion de projet, l’expérience commune suggère que de nombreux projets échouent (Williams, 2005), ce qui souligne l’importance et la nécessité d’améliorer les processus de gestion de projet et le rendement.
En général, les organisations s’efforcent de mettre en œuvre les meilleures pratiques de gestion de projet traditionnelle — basées sur les normes PMI — pour atteindre les objectifs du projet et répondre aux attentes des clients. Cependant, tous les processus et pratiques recommandés du Corpus de connaissances sur la gestion de projet (Guide PMBOK®) peuvent ne pas être pertinents pour chaque projet. Souvent, une approche sélective est logique dans l’adoption de processus et de pratiques de gestion de projet pour répondre aux besoins spécifiques du projet en fonction de sa taille, de son type, de sa complexité et de l’industrie dans laquelle le projet est entrepris. Un tel besoin d’une approche différente de la gestion des projets INFORMATIQUES est bien documenté dans la documentation sur la gestion de projet.
Les projets de développement de logiciels sont souvent confrontés à des défis contradictoires consistant à développer des produits logiciels à un rythme accéléré tout en les développant avec une robustesse pour les rendre fiables (Boehm, 2002). Les projets informatiques, visant à suivre le rythme des développements technologiques en évolution rapide, subissent souvent des changements de portée au cours des étapes de planification et de mise en œuvre. Par conséquent, les projets informatiques présentent des défis différents des projets traditionnels. Plusieurs ajustements et modifications aux pratiques traditionnelles de gestion de projet sont développés et pratiqués pour les projets informatiques, introduisant ainsi de nouvelles méthodologies de gestion de projet telles que la gestion de projet agile.
La méthodologie de gestion de projet Agile — avec sa plus grande adaptabilité à une portée changeant fréquemment – utilise une planification itérative ou progressive et une intégration continue. Le principe clé est de garder la portée du projet douce. La méthodologie favorise la collaboration et se traduit par une satisfaction accrue des clients. Cependant, agile n’est pas une solution complète pour développer des logiciels à un rythme rapide tout en répondant aux exigences de robustesse et de fiabilité des clients. Dans ce contexte, Boehm (2002) a recommandé une combinaison de la gestion de projet traditionnelle et de la méthodologie de développement logiciel agile qui soit faisable et préférable. Une approche complémentaire consisterait à développer une approche basée sur le risque qui soit adaptée pour conserver les avantages des méthodes agiles et axées sur le plan tout en atténuant bon nombre de leurs faiblesses (Boehm & Turner, 2003).
Ce document de recherche vise à examiner les propositions ci-dessus (Boehm, 2002; Boehm & Turner, 2003) d’une approche combinée de gestion de projets de conseil en informatique, qui sont différentes des projets informatiques. Les projets de conseil en informatique sont conçus pour gérer et soutenir des projets informatiques. Ils sont souvent initiés dans le secteur public. Les projets de conseil en TI ne sont pas des projets de développement de logiciels; ils fournissent plutôt un soutien de projet aux projets informatiques.
Dans cette étude, nous visons à développer une compréhension de la pertinence des pratiques de gestion de projet agiles pour les projets de conseil en informatique. Les objectifs de l’étude sont d’identifier les avantages de l’utilisation de la gestion de projet agile, sa pertinence et quels aspects de la gestion de projet traditionnelle peuvent être combinés à la gestion de projet agile pour les projets de conseil en informatique afin d’améliorer les performances du projet. Dans la section suivante, à l’aide d’une analyse documentaire approfondie de la méthodologie de gestion de projet agile, nous avons identifié les principales caractéristiques de la méthode agile et leur approche unique de la gestion de projets par rapport à la gestion de projet traditionnelle. La revue de la littérature a permis de mieux comprendre les concepts clés et les avantages de l’utilisation du développement logiciel agile. De plus, sur la base des résultats de l’examen de la littérature, nous avons développé et présenté une méthode de recherche utilisant un questionnaire structuré pour développer une compréhension des projets de consultation en TI. L’analyse et la discussion des données, présentées ultérieurement, fournissent des informations et des conclusions importantes de l’étude. Nous concluons le document avec nos résultats de recherche et nos recommandations pour les projets de conseil en informatique.
Revue de la littérature
Les pratiques traditionnelles de gestion de projet, qui reposent sur une planification exhaustive, peuvent être utilisées lorsque les spécifications du projet sont clairement définies. D’autre part, lorsque les spécifications sont sujettes à de fréquents changements au cours de la vie du projet, l’approche traditionnelle de la gestion des projets peut ne pas fonctionner efficacement. Les projets de développement logiciel sont souvent conçus avec des spécifications minimales, ce qui entraîne des modifications fréquentes de ces spécifications lors de la mise en œuvre du projet. De plus, les durées de développement de projets logiciels sont courtes. Les méthodes agiles, comparées aux techniques traditionnelles de gestion de projet, conviennent aux projets de développement logiciel en raison de la courte durée de développement de ces projets (Hanakawa & Okura, 2004).
En général, diverses méthodes de développement de logiciels telles que la gestion de projet agile promettent une satisfaction client accrue, des taux de défauts plus faibles, des temps de développement plus rapides, et elles servent de solution à l’évolution rapide des exigences du projet (Boehm & Turner, 2003). Contrairement à la gestion de projet agile, un modèle stage-gate utilise un processus de travail allant de l’idée de concept à un produit qui est finalement livré. Ce modèle développe des phases de cycle de vie de gestion de projet basées sur différentes étapes de développement de produits pour la gestion de projets. Une distinction importante entre un modèle de porte d’étape et une gestion de projet agile est que le premier tente de minimiser les changements d’exigences afin que le produit soit terminé à temps (Karistrom & Runeson, 2005). Une autre méthode de développement de logiciels est SCRUM, qui est un ensemble de principes de gestion de projet employant de petites équipes interfonctionnelles et autogérées (Schatz & Abdelshafi, 2005). SCRUM exige que chaque membre de l’équipe et chaque product owner travaillent ensemble au début de chaque élément de développement et que la méthodologie agisse comme un wrapper autour des processus de développement existants. Par conséquent, Schatz et Abdelshafi ont fait valoir que SCRUM n’aura pas de plan de base pour mesurer le succès du projet. Cependant, la gestion de projet agile est prise en compte pour cette étude en raison de sa plus grande flexibilité et de sa plus grande adaptabilité aux projets de développement logiciel.
En plus des avantages discutés ci-dessus, la méthodologie agile est applicable à des environnements turbulents et en constante évolution (Highsmith & Cockburn, 2001). De plus, la méthode agile met l’accent sur l’adaptabilité au marché, à la technologie et aux processus (Mellor, 2005). La méthodologie agile est une approche qui se concentrera d’abord sur les fonctionnalités importantes et, par conséquent, elle recherchera un retour d’information précoce sur les fonctionnalités (Karistrom & Runeson, 2005). Une fois les caractéristiques importantes identifiées, le gestionnaire de projet veillera à ce qu’il n’y ait pas de retards. Karistrom et Runeson ont indiqué que le processus agile éviterait l’entassement des ressources, les plans fixes et le soutien des plans à long terme.
Cependant, la méthodologie agile ne convient pas à tous les projets de développement logiciel. Citant Scott Ambler, le développeur de la méthode agile, Boehm (2002) a recommandé une méthodologie de gestion de projet traditionnelle basée sur un plan pour les logiciels d’assurance tels que les systèmes vitaux.
La méthode agile, en raison de son environnement de projet exigeant caractérisé par le chaos et l’incertitude, nécessite des équipes de projet composées de personnes talentueuses pour répondre aux besoins et aux demandes difficiles. Citant une étude de Constantine (2001), Boehm (2002) a suggéré que les méthodes agiles nécessitent des personnes hautement compétentes. De plus, agile ne convient pas aux équipes plus importantes (Highsmith & Cockburn, 2001), car elle nécessite un travail d’équipe étroitement coordonné pour réussir, et les équipes comptant plus de 15 ou 20 développeurs augmentent la difficulté de gérer le projet (Constantine, 2001).
Il est évident que la méthode agile emploie des équipes cohérentes (Karistrom & Runeson, 2005). Karistrom et Runeson ont identifié des fonctionnalités agiles supplémentaires, telles que des tâches petites et faciles à gérer, une intégration continue et des tests automatiques. Par conséquent, les équipes de projet agiles se caractérisent par une bonne communication interne, une qualité supérieure et un sentiment de contrôle (Karistrom & Runeson). Ils envisagent cependant un isolement potentiel pour l’équipe agile.
En termes de communication, de gestion documentaire des progrès et de contrôle de la qualité, une pratique courante dans la gestion de projet traditionnelle ne correspond pas à la méthode de développement logiciel agile (Hanakawa & Okura, 2004). L’interaction face à face pour un réalignement continu des objectifs de développement est généralement préférée dans les méthodologies agiles (Melnik & Mauer, 2004). Soulignant la différence entre les méthodes traditionnelles et agiles, Melnik et Mauer ont suggéré que le transfert de connaissances court et la communication et la collaboration directes sont préférées dans le développement de logiciels, contrairement aux pratiques traditionnelles de gestion de projet, où de longues chaînes de transfert de connaissances sont utilisées, qui sont souvent sensibles à la distorsion et à la perte d’informations.
L’une des différences importantes entre les pratiques de gestion de projet traditionnelles axées sur les plans et les méthodes agiles est que les méthodes agiles capturent l’agilité des connaissances tacites de l’équipe de projet plutôt que des connaissances explicites, souvent utilisées sous forme de documents et de plans dans la gestion de projet traditionnelle (Boehm, 2002).
Une autre différence est la quantité et le type de documentation créée pour les projets. La gestion de projet traditionnelle axée sur le plan met l’accent sur la planification détaillée, la surveillance et le contrôle des documents. Les justifications de conception, documents qui expriment des raisons et des justifications, sont créés à l’aide d’une procédure hautement automatisée et ces justifications de conception servent de documentation agile (Sauer, 2003).
Coram et Bohner (2005) ont identifié des caractéristiques communes de la méthode agile : collaboration, petites équipes, calendriers de publication courts, time boxing et tests constants. Le chef de projet est responsable d’assurer un environnement hautement collaboratif. Pour cela, la méthode agile encourage les petites équipes et quelques sous-équipes par projet à favoriser la collaboration. En conséquence, la méthode agile nécessitera probablement moins de processus et de planification pour coordonner les activités de l’équipe. La méthode agile utilise également des calendriers de publication courts, qui peuvent varier de deux semaines à six mois. Le Time boxing est un concept qui impose une durée fixe pour la publication des livrables du projet, ce qui contribue à réduire le placage à l’or et le fluage de la portée. Des tests constants garantissent la qualité et l’intégration des produits. En outre, Coram et Bohner ont suggéré que les gestionnaires de projet doivent suivre les progrès et prendre des décisions d’affaires en mettant l’accent sur la réponse au changement plutôt que de suivre un plan spécifique.
La boxe du temps conduit à une planification imprévisible selon les meilleures hypothèses et des dates fixes pourraient entraîner des surprises inattendues pendant la phase de développement (Patton, 2003). Un autre résultat de ce processus de planification de projet itératif est que la méthode agile ne peut pas suivre les progrès en fonction du pourcentage d’achèvement (Patton, 2003).
La participation de petites sous-équipes à la planification entraînera des ingénieurs de développement de logiciels motivés; des problèmes techniques sont soulevés au début du projet et il y aura peu de résistance à la mise en œuvre (Karistrom & Runeson, 2005). De plus, la définition de la portée du projet avec une approche agile entraînerait une réduction des coûts (Mcgovern, 2002). La méthode agile utilise une planification basée sur les exigences et nous permettra également de contrôler la portée (McGovern).
En utilisant toutes les références et discussions jusqu’à présent et d’autres (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), le tableau 1 fournit une comparaison sommaire entre les pratiques de gestion de projet traditionnelles et agiles .
Tableau 1: Comparaison entre la Gestion de Projet Agile et Traditionnelle
| Phase du projet | Traditionnel | Agile |
| Initiation |
|
|
| Planification |
|
|
| Execution |
|
|
| Surveillance et Contrôle |
|
|
| Fermer |
|
|
Résumé de la revue de la littérature
La méthodologie de gestion de projet agile est couramment utilisée pour les projets de développement de logiciels. Il a une plus grande adaptabilité à la portée changeante fréquemment. En conséquence, la gestion de projet agile utilise une planification itérative ou progressive et une intégration continue tout au long de la vie du projet. Le principe clé de la gestion de projet agile est de garder la portée du projet douce. La méthode de gestion de projet agile se distingue d’une méthode de gestion de projet traditionnelle en attribuant de l’importance à des facteurs traditionnellement considérés comme sans importance. Agile attribue une importance relativement plus élevée à:
- Les individus et les interactions sur les processus et les outils
- L’exécution du projet sur une documentation complète
- La collaboration avec les clients sur la négociation de contrats
- La réponse au changement sur un plan de projet
La méthode agile met l’accent sur la flexibilité pour répondre aux besoins du projet. De plus, il s’appuie sur les commentaires des clients pour initier des modifications à un plan de projet. La méthodologie utilise l’approche consistant à identifier les utilisateurs finaux appropriés et leurs objectifs pour formuler les livrables du projet et répondre aux besoins performants des processus métier. Les avantages de l’utilisation de la méthode agile incluent une satisfaction client accrue, des taux de défauts plus faibles et des temps de développement plus rapides. De plus, la méthode agile est une réponse aux exigences en évolution rapide, car elle utilise un retour d’information précoce sur les caractéristiques technologiques des livrables du projet. La méthode agile garantit que les exigences ne sont pas entassées. Les principales caractéristiques de la méthode agile sont une communication efficace au sein et à l’extérieur de l’équipe de projet, et une flexibilité démontrée pour ajouter plus d’exigences.
Ces avantages aideraient les organisations à offrir un meilleur service à la clientèle. En outre, ils sont pertinents dans l’économie actuelle où la mondialisation et une philosophie de marketing libre affectent les perceptions des clients en augmentant les attentes de fournir des produits et / ou des services plus rapidement, moins chers et meilleurs.
Cependant, la méthode agile n’est pas sans défauts, comme on peut le voir dans le tableau 1. L’évolution fréquente de la portée rend difficile le suivi de l’avancement du projet. En outre, il n’est pas facile de saisir des connaissances tacites sous la forme d’enseignements tirés. Le contrôle du changement de portée, la documentation, le plan complet, la gestion de la qualité et la gestion des risques sont des avantages importants de la gestion de projet traditionnelle dont nous pouvons être privés lorsque nous utilisons la méthode agile.
Méthodologie de recherche
Nous avons utilisé des entrevues personnelles et des questionnaires pour recueillir les données. Nous avons développé un questionnaire structuré composé de deux sections. La première section a été conçue pour saisir des détails sur le projet et ses caractéristiques. Cette section comprend 13 questions liées aux données démographiques et aux pratiques de gestion de projet. Ils ont été présentés aux participants à l’étude avec la possibilité de fournir des réponses ouvertes si nécessaire.
La deuxième section portait sur les énoncés de pratiques de gestion de projet, et les participants ont été invités à répondre à ces énoncés sur une échelle de cinq points, 1 indiquant » tout à fait en désaccord » et 5 indiquant » tout à fait d’accord « . »Les énoncés suivants ont été utilisés pour aborder d’importants principes communs des pratiques de gestion de projet, ainsi que pour opposer les pratiques de gestion de projet traditionnelles et agiles.
- Les critères de mesure de la réussite du projet sont basés sur les objectifs et les buts du projet.
- Le projet est motivé par les exigences.
- Le projet est adaptable au changement.
- À votre avis, les efforts de gestion de projet ont permis d’atteindre les résultats attendus
- Les interactions en face à face et les chaînes de communication plus courtes sont plus importantes que les processus et les outils.
- L’équipe se concentre sur l’exécution du projet plutôt que sur une documentation complète.
- La collaboration avec les clients plutôt que la négociation de contrats fonctionne mieux pour votre équipe.
- La portée du projet est bien définie.
- Les pratiques de gestion de projet suivent le cycle de vie du projet du Guide PMBOK®.
- La planification itérative ou progressive du projet est suivie pour le projet.
- Le projet a des exigences de documentation telles que le respect de normes telles que ISO9000, OMB 300.
- Les procédures de test d’acceptation par l’utilisateur (UAT) sont suivies tout au long du projet.
- Le chef de projet est habilité à prendre des décisions liées au projet sans intervention du client.
Les réponses à ces énoncés sont analysées conjointement avec les questions appropriées de la première série de 13 questions. Ensemble, les réponses aux deux sections ont fourni une compréhension détaillée du projet pour une analyse significative.
Résultats de l’étude
Le questionnaire a été structuré de manière à recueillir des données sur 20 projets de consultation en TI, qui étaient en cours au moment de la recherche. Parmi les projets, 65% sont des projets de type contrat de temps et de matériel et les autres sont de type prix fixe ferme (FFP). Parmi les projets de temps et de matériel, 55% ont une durée de projet de plus de deux ans.
La plupart des équipes de projet sont petites : seulement 15% comptent 10 membres ou plus. En ce qui concerne la communication entre les membres de l’équipe de projet, 60% des répondants n’ont utilisé que la communication formelle pour les besoins du projet; 30% ont utilisé des communications formelles et informelles, et les 10 % restants se sont appuyés uniquement sur des méthodes informelles.
Un répondant sur deux a indiqué que ses projets ont utilisé un plan de projet. Dans une question connexe, parmi les projets qui n’avaient pas de plan de projet, 80% n’utilisaient pas non plus de planification itérative.
Le changement de portée est un aspect important de cette étude. Parmi les projets, 70% ont subi un changement de portée au moins une fois. Parmi ceux qui ont subi un changement de portée du projet, 60% l’ont vécu plus de deux fois. Pendant que le client décide du changement de portée, le consultant — avec le consentement du client – peut inclure le plan de contrôle de la qualité dans le plan de gestion du projet. Lorsqu’on leur a demandé s’ils avaient un plan de contrôle de la qualité pour leur projet, 65 % des répondants ont indiqué qu’ils n’avaient pas utilisé de plan de contrôle de la qualité.
Résultats Discussion et analyse
Les résultats de la recherche ont été analysés en examinant attentivement toute corrélation entre une question et toutes les autres questions, d’abord pour valider les résultats et ensuite, pour élaborer des stratégies de gestion efficaces. De plus, ces résultats ont été analysés en vue d’examiner quelles pratiques de gestion de projet agiles et traditionnelles peuvent être utilisées en combinaison pour développer une approche de gestion de projet robuste pour les projets de conseil en informatique.
Critères de réussite du projet En fonction de ses objectifs et buts
Un projet est considéré comme réussi lorsqu’il atteint ses objectifs et buts. Seuls 60% des répondants ont souscrit à la déclaration, « Les critères de mesure de la réussite du projet sont basés sur les objectifs et les buts du projet. » Environ 30% des répondants n’étaient pas d’accord. Une analyse plus approfondie a montré que la raison du désaccord était que ces projets connaissaient des conditions et des exigences en constante évolution, ou que le client n’était pas clair sur le projet. En fin de compte, ces projets subissaient de fréquents changements de portée. Dans un cas particulier, les buts et objectifs du projet ont changé.
Il est intéressant de noter qu’il n’y a pas d’association entre le fait que les critères de réussite d’un projet découlent de ses objectifs et de son changement de portée, du type de projet et de l’existence d’un plan de projet. En d’autres termes, dériver les critères du projet du plan stratégique de l’organisation n’a aucune incidence sur le changement de portée et sur le fait que le projet a un plan.
Exigences du projet
Habituellement, un plan de projet détaillé est élaboré après que les exigences du promoteur du projet ont été clairement identifiées. L’élaboration du plan de projet et son exécution devraient en principe être dictées par ces exigences. Par conséquent, on pourrait s’attendre à ce que les gestionnaires de projet soient d’accord avec l’énoncé suivant: « Le projet est axé sur les exigences. »Les résultats de l’étude montrent que seulement 60% des répondants ont déclaré que leurs projets sont motivés par des exigences. Environ 20 % des répondants qui étaient en désaccord avec l’énoncé ont indiqué que leurs projets sont exécutés sans utiliser de plan de projet.
Environ 20 % des répondants qui étaient neutres en réponse à cette déclaration sont des gestionnaires de projet qui n’ont subi aucun changement de portée dans leurs projets. Tous les autres répondants, ceux qui étaient d’accord ou en désaccord avec l’énoncé, ont subi un changement de portée au moins une fois dans leurs projets en cours.
En général, si un projet n’est pas mis en œuvre conformément à son plan, nous pouvons supposer que les exigences ne sont pas identifiées ou que les exigences du projet devraient changer au cours de son exécution. Dans cette étude, cependant, nous ne pouvons pas établir une telle association entre « la mise en œuvre du projet sans utiliser le plan de projet » et le « le projet n’est pas motivé par les exigences », car seulement 50% de ceux qui ont accepté la deuxième déclaration ont également géré des projets sans utiliser de plan.
Adaptabilité au changement
Dix-huit projets sur 20 ont répondu aux changements du projet avec succès. L’adaptabilité au changement est considérée comme une caractéristique principale pour qu’un projet soit candidat à l’utilisation d’une méthodologie de gestion de projet agile. Les projets de conseil en ti représentés dans cette étude ont démontré leur capacité d’adaptation pour faire face aux changements de portée.
Les efforts de gestion de projet Ont permis d’atteindre Les résultats attendus
Les résultats indiquent que le client est satisfait des résultats dans la majorité des projets (70 %). Cependant, ces réponses n’étaient pas associées aux réponses à d’autres questions importantes du sondage sur l’avancement du projet et le produit élaboré du point de vue du gestionnaire de projet. Les raisons sont évidentes. Les projets subissaient toujours des dépassements de temps et de coûts. Bien que le résultat final de la livraison du produit logiciel soit satisfaisant, les processus de gestion de projet n’ont pas été exécutés avec succès. On pourrait en déduire que l’adoption de pratiques traditionnelles de gestion de projet, telles que l’élaboration de jalons, la surveillance et le contrôle, aurait aidé à gérer le projet avec succès.
Importance de la communication en face à face par rapport aux processus
La communication est la clé pour comprendre les rôles, les responsabilités, les politiques et les procédures liés aux projets et encourager la collaboration. En fin de compte, la communication mène à une équipe de projet cohérente et encourage les membres de l’équipe à collaborer et à participer à la prise de décision. Sept chefs de projet sur dix qui ont participé à l’étude ont convenu que les interactions en face à face et les chaînes de communication plus courtes avaient plus d’importance que les processus et les outils.
Les résultats montrent une forte association entre l’importance de la communication en face à face et les moyens de communication entre les membres de l’équipe du projet. Ceux qui n’étaient pas d’accord sur le fait que la communication en face à face est plus importante que les processus de projet ont utilisé la communication informelle entre les membres de l’équipe de projet, tandis que ceux qui considéraient la communication en face à face comme plus importante ont utilisé la communication formelle et informelle.
L’accent mis sur l’exécution du projet Plutôt que sur la documentation
La documentation du projet est souvent négligée et, par conséquent, les organisations sont privées d’importantes leçons apprises dans la planification et l’exécution du projet. Étant donné que tous les projets représentés dans cette étude sont des projets du gouvernement fédéral, il est intéressant de noter que 70 % des gestionnaires de projet ayant répondu ont convenu que leurs équipes se concentraient sur l’exécution du projet plutôt que sur la création d’une documentation complète. Dans quelques cas où les chefs de projet ont considéré que la documentation était plus importante que l’exécution du projet, une enquête plus approfondie a révélé que le client était indécis au sujet du projet dans tous ces cas.
La collaboration client Par rapport à la Négociation contractuelle
La négociation contractuelle est une caractéristique essentielle des projets externes. Au cours de la négociation, les deux parties se concentreraient sur la protection de leurs intérêts personnels. La négociation du contrat peut avoir lieu à différentes étapes du projet. Il est souhaitable de traiter ces questions par la collaboration, en particulier lors de la mise en œuvre du projet; sinon, cela entraînera des problèmes tels que la prolongation du contrat. Étant donné que tous les projets représentés dans cette étude sont des contrats, il est encourageant de noter que plus de la moitié des chefs de projet ayant répondu (60%) considèrent que la collaboration avec les clients est plus importante que la négociation de contrats. Ils ont suggéré que la collaboration fonctionne mieux pour les équipes de projet.
En cas de désaccord, ce qui implique que la collaboration n’est pas aussi importante que la négociation, deux faits intéressants ont été associés à ces projets. Tous les autres projets utilisaient le contact direct comme moyen de communication avec les parties prenantes du projet, mais ces projets utilisaient une communication par chaîne de commandement et le client était également indécis quant au projet. Ces deux facteurs impliquent des conditions de collaboration difficiles.
Projet et une Portée de projet bien définie
Les projets sont généralement associés à des incertitudes et à des facteurs inconnus, ce qui conduit à une ambiguïté. Par conséquent, la portée et les spécifications détaillées ne peuvent pas être élaborées au début du projet. La portée du projet change continuellement tout au long du projet. Parfois, les objectifs initiaux du projet peuvent également changer. Parmi les projets étudiés, 40 % ont une portée bien définie, tandis que 45 % ne l’ont pas fait.
Cependant, 80% des projets ont connu un changement de portée au moins une fois, ce qui valide les arguments présentés précédemment.
Pratiques de gestion de projet et Guide PMBOK® Cycle de vie du projet
Le Guide PMBOK® a développé un processus complexe de cycle de vie de gestion de projet; il est exhaustif et complet. Cependant, il n’est pas nécessaire que chaque processus du cycle de vie de gestion de projet du Guide PMBOK® soit appliqué à chaque projet. Son adoption devrait être spécifique au projet. Comme prévu, 45 % des chefs de projet ont suivi les pratiques de gestion de projet du cycle de vie du guide PMBOK®, et 45 % ne l’ont pas fait.
Planification itérative ou progressive du projet
La définition de la portée et le plan de gestion du projet font partie du plan de projet. Comme il a été mentionné précédemment, l’élaboration détaillée de la portée et des spécifications ne peut être élaborée au début du projet. Par conséquent, la portée du projet change continuellement tout au long du projet, ce qui souligne l’importance de la planification itérative ou progressive du projet, une caractéristique importante de la méthode agile. Lorsqu’on leur a demandé si la planification itérative ou progressive du projet était suivie pour le projet ou non, la moitié des répondants ont répondu oui, et seulement 15% n’ont pas suivi la planification itérative du projet. Il est intéressant de noter que tous ceux qui étaient en désaccord avec la pratique de la planification de projet itérative n’avaient pas de plan de projet en premier lieu.
Documentation et respect des normes
La documentation de projet sert de référence pour l’analyse des données historiques et aide les organisations à améliorer continuellement les processus de gestion de projet et à élaborer des normes. La documentation aidera également à identifier les leçons apprises et à modifier les systèmes de gestion de projet qui mèneront à la maturité de la gestion de projet. OMB300 et ISO9000 servent de guides dans la conception de systèmes de documentation de projet. Plus précisément, de nombreux projets gouvernementaux sont tenus de respecter les lignes directrices OMB300. Parmi les répondants, 80% ont déclaré que les projets informatiques qu’ils géraient avaient des exigences en matière de documentation telles que le respect de normes telles que ISO9000 et OMB300. Cependant, ces exigences pour les projets de conseil en TI sont applicables dans une mesure limitée.
Procédures de test d’acceptation par l’utilisateur
La satisfaction du client est la principale mesure de la qualité et du succès des éléments livrables du projet. Par conséquent, les procédures de test d’acceptation par l’utilisateur sont considérées comme importantes. Même dans le cas de livrables de projet moins tangibles tels que le service, la mesure sous-jacente de la réussite du projet est la satisfaction du client. Cependant, c’est subjectif. Seulement 30% des répondants ont déclaré avoir suivi les procédures de test d’acceptation des utilisateurs tout au long du projet, et 45% des répondants ne l’ont pas fait.
Habilitation à prendre des décisions liées au projet
En général, les gestionnaires de projet devraient avoir les mains libres pour prendre des décisions liées au projet sans intervention du client, lorsque ces décisions n’ont pas d’impact majeur sur la portée du projet ou les livrables du projet. Seuls 15% ont convenu que le chef de projet est habilité à prendre des décisions liées au projet sans intervention du client. Environ 40% sont restés neutres et les 45% restants ont déclaré que le chef de projet n’avait pas ce pouvoir. Étant donné que ces projets sont des projets externes et gouvernementaux, ces résultats ont du sens.
Conclusion
Les résultats de notre étude montrent que la majorité des projets sont motivés par des exigences. Presque tous les projets représentés dans cette étude ont démontré qu’ils sont adaptables au changement. La communication informelle est considérée comme plus importante que les processus et systèmes formels. Étant donné que les projets de l’étude sont liés au travail du gouvernement, les résultats montrent que l’équipe de projet s’est concentrée sur l’exécution du projet plutôt que sur une documentation complète. De plus, la collaboration avec les clients plutôt que la négociation de contrats fonctionne mieux pour les équipes de projet. Le changement fréquent de la portée du projet signifie l’importance de la planification itérative ou progressive du projet; une caractéristique importante de la gestion de projet agile. Étant donné que tous les projets de conseil en informatique représentés dans cette étude sont des contrats, les résultats de l’étude encouragent l’adoption formelle d’une méthodologie agile pour les projets de conseil en informatique et leur combinaison avec des pratiques traditionnelles de gestion de projet telles que le développement et le suivi d’étapes planifiées, les procédures d’acceptation par les utilisateurs et les pratiques de gestion de la qualité.
L’adéquation de la méthode agile pour les projets est une obligation contractuelle liée aux documents concernant la planification, le suivi et le contrôle des projets. Les projets associés au gouvernement fédéral ont généralement des exigences de documentation importantes, telles que le respect de normes telles que ISO9000 et OMB300; nous devons faire preuve de prudence en modifiant la méthode agile pour de tels projets.
Le défi consiste à maintenir l’agilité, la réponse rapide au changement, des plans flexibles et simples, l’intégration continue et d’autres avantages de la méthode agile tout en intégrant certains des processus complets des pratiques traditionnelles de gestion de projet.