IDENTIFICATION D'UN PROJET

Il est primordial pour l’ingénieur.e qui gère un projet de bien comprendre tous les défis que l’équipe devra relever. Il est donc essentiel que l’identification d’un projet soit effectuée de façon rigoureuse. Bien que la méthode présentée ne soit pas la seule élaborée par les milieux universitaire et d’affaires, elle reste un bon exemple à suivre pour que l’ingénieur.e gestionnaire de projet puisse mieux saisir les défis et les possibilités qu’offre le projet à son équipe.

À cet effet, les diverses analyses proposées doivent être réalisées et consignées dans un document, le MIP en l’occurrence, qui sera remis au client pour approbation. Dans la mesure du possible, l'ingénieur.e devrait procéder à de telles analyses, ne serait-ce que pour mieux comprendre les divers enjeux et la complexité du projet dont il est responsable.

Qu'est-ce qu'un projet?

Nombreux sont ceux qui ont tenté de définir la notion de projet, en voici deux exemples.

De telles définitions contiennent certaines caractéristiques dont il faut tenir compte lors de l’identification ou de la définition d’un projet. Ces caractéristiques sont les suivantes :

• la nouveauté, l’unicité (processus ou  résultat unique)
• une durée limitée (de façon ponctuelle)
• la présence d’un client pour qui le projet doit être réalisé
• l’assujettissement à des contraintes rigoureuses de performance, de délai, de qualité et de coût (contraintes budgétaires, matérielles, humaines et temporelles)

De plus, un projet est assujetti à plusieurs facteurs :

• un cycle de vie dynamique
• l’engagement de nombreux participants, d’intérêts, d’organisations, de disciplines et de cultures divers
• un contexte d’incertitude en matière d’environnement, de technologie et de ressources

Caractéristiques d’un projet

Qu'est-ce que la gestion de projet?

Le PMI définit la gestion de projet en ces termes : « L’art de diriger et de coordonner les ressources humaines et matérielles tout au long du cycle de vie d’un projet en utilisant des techniques de gestion appropriées pour atteindre des objectifs prédéterminés : d’envergure, de coûts, de délais, de qualité, de satisfaction du client et de satisfaction des participants. »

De cette définition, il faut retenir les notions suivantes :

• la gestion de projet est un art en plus d’être une science, car si nous utilisons des procédés et des techniques scientifiques pour la gestion, la définition introduit l’aspect « artistique » dans la gestion d’un projet. C’est dire que le gestionnaire de projet devra faire appel à des talents de créativité et d’intuition, en plus de ses connaissances techniques et scientifiques. L’aspect expérience peut jouer un rôle déterminant dans cette caractéristique artistique de la gestion de projet
• une coordination des ressources humaines et matérielles est obligatoire. Nous n’insisterons pas à ce stade sur l’aspect de la gestion des ressources humaines, celui-ci étant abordé dans d’autres volets de la gestion de projet. Cependant, retenons qu’en plus de veiller à une coordination des ressources humaines, le gestionnaire de projet doit s’assurer de mettre en place une « gestion humaine » des ressources, ce qui est fort différent de l’acception traditionnelle de la gestion des ressources humaines
• un projet a un cycle de vie propre qu’il faut caractériser selon l’environnement professionnel dans lequel le projet est exécuté
• l’atteinte d’objectifs prédéterminés en matière d’envergure, de coûts, de délais, de qualité peut être résumée par le triangle des compromis de la gestion de projet

Triangle des compromis de la gestion de projet

La caractéristique de « satisfaction du client » place le client au centre des préoccupations du gestionnaire de projet. Le projet est exécuté parce que le client a donné un mandat à l’ingénieur gestionnaire de projet. Sans client, le projet n’existe pas.

La caractéristique de « satisfaction des participants » demeure une contrainte difficile. En plus du client, le gestionnaire de projet doit s’assurer que tous les participants sont satisfaits à la fois de leur travail ou de leur intervention dans le projet, et du produit final. Le gestionnaire de projet doit donc être en mesure d’appliquer une gestion humaine des ressources et non pas se satisfaire d’une coordination maximale ou optimale des ressources disponibles pour l’exécution du projet.

Facteurs clés du succès d’un projet

Pour assurer le succès d’un projet, quels sont les facteurs nécessaires? Plusieurs études et analyses ont été effectuées afin de déterminer ces facteurs. Deux d’entre elles se démarquent.

La première étude, réalisée par Pinto et Slevin en 1989, énumère les facteurs de succès, classés ces facteurs par ordre d’importance, à la suite de l’analyse de 400 projets dans le secteur des TI (le texte entre parenthèses est ajouté pour une meilleure compréhension des intitulés) :

• mission du projet (buts et objectifs clairs)
• soutien de la haute direction
• plan et échéancier (y compris les plans et les devis détaillés)
• engagement du client et consultation de ce dernier
• personnel (prenant part au projet)
• tâches techniques du projet (expertise et complications)
• acceptation par le client (des livrables du projet)
• surveillance du projet et rétroaction (contrôle et suivi)
• communication
• dépannage (troubleshooting)

Pour leur part, Belassi et Tuket ont aussi étudié et analysé divers projets réalisés entre 1971 et 2002. Les facteurs de succès suivants résument les résultats de cette analyse :

• définition de la mission et des buts :
  • définition des buts, de l’ampleur du travail (scope) et des besoins du client;
• soutien de la haute direction :
  • engagement continu
• engagement du client
• gestionnaire du projet :
  • compétence et engagement « terrain »
• autres facteurs :
  • équipe de projet, main-d’œuvre, précision des estimations, contrôle et suivi

Dans ces études, trois facteurs représentent une constante dans le succès de tous les projets,et ce, quelle que soit leur nature, pas seulement dans le domaine des TI : une énumération claire des objectifs du projet, l’engagement du client et le soutien de la haute direction.

Gestion par projets

Il existe une différence entre « la gestion de projet » et la « gestion par projets ». Cette dernière expression exprime une philosophie de travail qui s’inspire des notions de gestion de projet dans la gestion quotidienne et dans les divers processus de gestion. Dans la pratique, cette nuance n’est cependant pas très utilisée.

Cycle de vie d’un projet

Un projet se démarque par son cycle de vie, qui est généralement présenté comme étant constitué de phases. Le nombre de phases ainsi que leur appellation peuvent varier d’une application à une autre, d’un domaine d’application à un autre et d’un auteur à un autre. L’ingénieur responsable d’un projet devra parfois définir les phases du projet dont il a la responsabilité en tenant compte des paramètres propres au projet ou à la culture d’entreprise. Ces différences ne limitent en aucune façon la validité ni la pertinence du modèle ci-dessous en quatre phases qu’il est proposé à l’ingénieur de suivre.

• Phase d’identification : la demande est clarifiée, les objectifs précisés et le projet globalement identifié en ce qui a trait au produit ou au service à livrer, aux contraintes à respecter et à la stratégie de réalisation.
• Phase de définition : le contenu du projet est défini de façon plus précise, une planification détaillée est établie pour sa durée; les échéances, les ressources et les dépenses, ainsi que les politiques et les procédures de gestion sont circonscrites.
• Phase de réalisation : le produit ou le service est effectivement réalisé suivant le plan prévu et en conformité avec les exigences du demandeur.
• Phase de clôture : le produit ou le service est remis au demandeur, le projet est évalué et sa clôture administrative effectuée.

On distingue différents cycles de vie en fonction d’un projet, non seulement selon les auteurs, mais aussi selon les domaines, comme la construction, la recherche universitaire et le génie logiciel (méthode Scrum).

Cycle de vie selon le site ProjectWare

Le cycle de vie d’un projet, présenté sur le site de ProjectWare, se caractérise par les livrables de chacune des phases. Il est fondamental que le gestionnaire de projet décrive clairement les divers livrables des phases qu’il aura définies pour le projet.

Le cycle de vie selon le site ProjectWare (source : téléchargement le 21/09/2008, ProjectWare.com)

Cycles de vie des projets selon Wysocki

Wysocki (2003 et 2007) distingue les cycles de vie des projets selon trois méthodes de gestion de projet : la méthode « traditionnelle » , la méthode « adaptative » et la méthode « extrême ». Dans son ouvrage de 2007, il ajoute certains concepts qui approfondissent des méthodes se situant entre les divers cycles mentionnés ci-dessus.

Cycle de vie d'un projet de construction

Dans le cycle de vie d’un projet de construction, il faut noter la cooccurrence des activités de transfert et d’opération, comme l’illustre la figure suivante. En effet, certains projets vont obliger le mandataire à effectuer des opérations (« Operate ») avant la remise au client ou, notamment dans les cas de projets BOT( « Buid-Operate-Transfer »), à former le client en ce sens.

Cycle de vie type d’un projet de construction

Cycle de vie dans le domaine de la recherche universitaire

Le cycle de vie d’un projet de recherche universitaire est surtout caractérisé par les diverses itérations chronologiques qui peuvent influencer les résultats précédents. Le chercheur doit, à un moment donné, arrêter sa recherche et se consacrer à la rédaction d’un rapport, d’un article ou d’une thèse, car sa recherche documentaire ou sur le terrain risque d’atteindre un point de saturation. De nouvelles données n’apportent plus de substance nouvelle.
 

Cycle de vie dans le domaine du génie logiciel - la méthode Scrum

Le génie logiciel a dû adapter les méthodes traditionnelles de gestion de projet et, dans certains cas, réinventer la façon de faire. La méthode Scrum a été expressément mise au point pour les projets en génie logiciel. La méthode Scrum utilise une planification à trois niveaux : « release » /projet, « sprint » et quotidien.

Analyse préliminaire d’un projet

Bien qu’il ne participe pas nécessairement à l’identification d’un projet, lors de la prise en charge, l’ingénieur devrait analyser les divers aspects dont il aura la responsabilité, afin de clarifier les objectifs du client ainsi que ceux de son entreprise, et s’assurer de sa compréhension des enjeux. En, effet, ces derniers peuvent être négligés dans la fébrilité des activités de démarrage du projet et les obligations professionnelles quotidiennes. Cette analyse peut être mentale ou écrite, mais dans tous les cas, l’ingénieur devrait s’y astreindre avec rigueur. Elle portera sur l’environnement du projet, les parties prenantes, les risques et la préfaisabilité. L’utilisation de l’outil appelé cadre logique aidera l’ingénieur à mieux effectuer et synthétiser son analyse avant la mise en forme au moyen du Mémoire d’identification de projet (MIP).

Analyse de l'environnement

Tout projet se déroule dans un environnement qui peut être complexe et varier d’un projet à un autre. Par exemple, un projet exécuté dans un milieu syndiqué ne sera pas géré de la même façon qu’un projet issu d’un cadre de travail non syndiqué. Avant de commencer le projet, le gestionnaire analysera de manière exhaustive son environnement et celui du projet, afin d’en comprendre les enjeux et les contraintes potentielles.

Dans son édition 2004 du PMBOK®, le Project Management Institute (PMI) énumère trois types d’environnement

• l’environnement culturel et social
• l’environnement international et politique
• l’environnement physique

Bien que ces trois catégories englobent la majorité des environnements d’un projet, il est de la responsabilité de l’ingénieur gestionnaire de bien définir ceux de son projet.

O’Shaughnessy (1992), pour sa part, définit l’environnement interne et externe du projet.

L’environnement interne fait référence aux diverses variables de l’organisation d’où est issu le projet, alors que l’environnement externe touche aux variables qui sont indépendantes de la volonté de l’entreprise et qui peuvent influencer la bonne marche du projet.

Le tableau ci-contre résume les principales composantes de chaque environnement selon O'Shaughnessy.
 

Exemple de document type pour une analyse de l’environnement d’un projet (source projectware.com)	Exemple d’analyse de l’environnement d’un projet de déplacement d’une entreprise (source projectware.com)

L’analyse des partie prenantes

Le gestionnaire de projet doit aussi s’assurer de bien connaître toutes les parties prenantes du projet. Une partie prenante est ainsi définie par le PMI (2004) : « les personnes et les organisations activement impliquées dans le projet. Elles peuvent aussi influencer les objectifs et les résultats du projet. L’équipe de management de projet doit identifier ces parties prenantes, déterminer leurs exigences et leurs attentes et, dans la mesure du possible, gérer leur influence par rapport aux exigences de façon à assurer le succès du projet. » D’autres méthodes peuvent être utilisées, comme celle proposée par ProjectWare ou encore pour un projet de déplacement d’une entreprise.
 

Exemple de document type pour une analyse des parties prenantes d’un projet (source projectware.com)	Exemple d’analyse des parties prenantes d’un projet de déplacement d’une entreprise (source projectware.com)

Gestion du risque

Durant la phase d’identification, l’analyse du risque demeure au stade préliminaire. Le gestionnaire de projet effectuera une analyse des risques plus approfondie lors de la planification détaillée du projet. Cependant, il doit cerner dès le départ les principaux risques du projet, et ce, de façon aussi rigoureuse que durant la phase de définition, même s’il ne possède pas toute l’information nécessaire pour une analyse plus poussée. Il est clair qu’elle sera bonifiée au fur et à mesure que de nouvelles données seront disponibles ou découvertes. Le cadre logique apporte un premier éclairage sur les risques en repérant les conditions critiques du projet. Cependant, pour la planification détaillée, cette première analyse devient rapidement dépassée.

Le PMI définit le risque comme étant « un événement ou situation dont la concrétisation, incertaine, aurait une incidence positive ou négative sur les objectifs du projet ».

Le PMBOK® établit des catégories de risques et une structure de découpage des risques, selon leurs origines : techniques, externes, organisationnels, environnementaux ou de gestion du projet. La figure suivante illustre un exemple de structure de découpage des risques extrait du PMBOK®.

Exemple de structure de découpage des risques (d'après le PMI, « Corpus des connaissances en management de projet », 3e édition,2004, p. 244)

Toujours selon le PMBOK®, on distingue l’analyse quantitative de l’analyse qualitative du risque. La première analyse évalue la gravité du risque et la probabilité de modification inhérente au projet. Dans la seconde, le gestionnaire veille à la mise en place de mesures de probabilité du risque et de son effet sur le projet.

Selon le domaine d’application, il existe un grand nombre d’outils portant sur la reconnaissance des dangers et des risques associés à un procédé ou à une installation. Lors de l’analyse plus approfondie, l’ingénieur.e utilisera des méthodes informatiques plus élaborées, comme les analyses de scénarios, de sensibilités, de simulation Monte Carlo, ainsi que des logiciels, comme Crystal Ball d’Oracle et @Risk de Palisade. L’ingénieur.e pourra s’approprier le tableau 4, qui porte sur l’analyse préliminaire du risque en milieu pharmaceutique, et le modifier selon les besoins et l’environnement du projet dont il ou elle est responsable.
 

Définition d’échelles d’impact pour quatre objectifs du projet (Source : PMI, Corpus des connaissances en management de projet, 3e édition,2004, p. 245) 

Réponse aux risques

La mise en œuvre de stratégies de réponse est le processus qui consiste à élaborer des solutions et à déterminer des actions visant à susciter les occasions de réduire les menaces qui modifieraient les objectifs du projet. Elle nécessite l’identification des parties ou des individus auxquels sera confiée la responsabilité de chacune des stratégies de réponse approuvées. Ce processus permet de s’assurer que les risques repérés seront gérés de façon appropriée. L’efficacité de la planification des stratégies de réponse aura une influence directe sur l’augmentation ou la baisse du niveau global de risques du projet.

Plusieurs stratégies de réponse sont envisageables. Pour chaque risque, le choix doit porter sur la plus efficace selon le contexte, les circonstances, la ou les culture(s) en place (ex. d’entreprise, professionnelles, locales) ou tout autre aspect pouvant influer sur le projet et les décisions à prendre. L’ingénieur retiendra essentiellement les quatre stratégies de réponse aux risques suivantes : le rejet ou l’évitement, le transfert, l’atténuation ou la réduction, et l’acceptation.

• Le rejet d’un risque consiste à modifier le plan de projet afin d’éliminer le risque ou la circonstance, ou encore de préserver l’atteinte des objectifs du projet de ses conséquences. Le fait d’opter pour un type de langage plutôt qu’un autre (ex. C++) pour le développement d’un logiciel, parce que les membres de l’équipe connaissent ce langage, est une stratégie de rejet type.
• Le transfert des risques vise à transférer à une tierce partie les conséquences d’un risque et la responsabilité de la stratégie de réponse correspondante. Transférer le risque à une tierce partie n’élimine pas le risque. Une assurance automobile est l’exemple type de transfert de risque.
• La réduction d’un risque a pour objet d’atténuer la probabilité ou les conséquences d’une menace jusqu’à un seuil acceptable. Prendre à temps des mesures visant à réduire la probabilité de la concrétisation d’un risque ou de son effet sur le projet est plus efficace que d’essayer d’en réparer les conséquences une fois le risque concrétisé. Les coûts de la réduction doivent être proportionnels à la probabilité du risque et de ses conséquences. Les cautionnements de soumission sont des exemples de réduction de risque.
• L’acceptation d’un risque indique que l’équipe de projet a décidé de ne pas modifier le plan de projet pour affronter le risque, ou qu’elle n’est pas en mesure de trouver d’autres stratégies de réduction convenables. L’acceptation active peut inclure l’élaboration d’un plan de remplacement à mettre en œuvre au cas où un risque devenait réalité.  

Analyse de préfaisabilité

Les études de préfaisabilité et de faisabilité portent essentiellement sur les mêmes variables ou composantes du projet, mais à des niveaux d’analyse qui diffèrent en matière de profondeur ou de détails, et de l’effort, en heures et en coût financier. L’étude de préfaisabilité consiste à énoncer un ensemble de questions clés, dont les réponses permettront de porter un premier jugement sur le projet. Cependant, selon O’Shaughnessy (1992, p. 64), il faut rappeler que ce type d’étude a pour principaux objectifs d’analyser de façon non détaillée la faisabilité du projet sous divers angles (marché, technique, financier, etc.), de cerner les aspects du projet nécessitant une étude approfondie, de déterminer si on doit poursuivre le projet avec ou sans étude de faisabilité, de réviser le projet s’il y a lieu, ou de décider de l’abandonner à ce stade. Il est clair cependant que l’ingénieur ne sera pas appelé à exécuter certaines analyses qui n’entrent pas dans son champ de compétence. En sa qualité de professionnel, l’ingénieur doit être ouvert à un questionnement afin de mieux comprendre les raisons qui ont conduit à la réalisation du projet. Ce questionnement ne peut qu’être avantageux et sain pour le succès du projet, ne serait-ce que pour mieux définir les besoins du client.

Préfaisabilité de marché ou des services

• Le produit ou le service déterminé est-il le bon produit, répond-il aux besoins et aux exigences du client?
• Le produit ou le service est-il clairement défini, et le client approuve-t-il sa définition?
• Dans un environnement de production donné, le marché peut-il absorber une quantité raisonnable de ce genre de produit ou service pour le promoteur?
• À quel prix peut-on espérer vendre le produit ou le service, et quelle sera l’évolution du marché?
• Est-ce que tous les participants ont la même compréhension du projet?

Préfaisabilité technique

• Le projet fait-il appel à une technologie connue et maîtrisée ou faut-il d’abord maîtriser la technologie proposée?
• Le projet est-il techniquement réalisable?
• Les ressources techniques nécessaires pour l’exécution du projet sont-elles disponibles?
• Le personnel est-il convenablement formé pour la technologie proposée?
• Le calendrier d’exécution est-il réaliste et les ressources humaines sont-elles disponibles durant les périodes de réalisation du projet?
• Quelles sont les conséquences du projet sur le fonctionnement actuel de l’entreprise?

Préfaisabilité économique et financière

• Les estimations préliminaires du projet sont-elles réalistes?
• Les revenus projetés sont-ils réalistes comparativement à ce qui a été réalisé dans le passé?
• Quels sont les flux monétaires préliminaires du projet?
• Une analyse financière préliminaire a-t-elle été réalisée?
• Divers scénarios financiers ont-ils été élaborés?
• Comment le projet sera-t-il financé?
• Quelles sont les perspectives de rentabilité du projet, à court, moyen et long termes?

Préfaisabilité sociopolitique

• L’entreprise dispose-t-elle des ressources humaines nécessaires à l’exécution du projet?
• Quelles sont les possibilités de recrutement dans les domaines visés en cas de manque de ressources, à court, moyen et long termes?

Préfaisabilité institutionnelle et légale

• Quels sont les règlements, les lois et les us et coutumes (éthique, culture professionnelle et d’association) qui régissent la réalisation du projet?

Préfaisabilité organisationnelle

• L’entreprise dispose-t-elle de l’organisation appropriée pour la réalisation du projet?
• Selon le financement prévu, sera-t-il nécessaire d’approcher des partenaires?
• Comment un partenariat serait-il perçu par les dirigeants de l’entreprise?

Préfaisabilité environnementale

• Le projet a-t-il un impact social?
• Quel sera l’effet sur l’organisation?
• Existe-t-il des normes environnementales et sociales pouvant empêcher ou menacer les objectifs du projet?
• Si le projet se réalise sur un site autre que celui où œuvre l’entreprise, existe-t-il des contraintes environnementales ou sociales qui peuvent nuire au projet?  

Cadre logique

La méthode du cadre logique est un outil qui permet de synthétiser les données connues d’un projet. Il existe plusieurs modèles, dont celui élaboré par l’Agence canadienne de développement international (ACDI) (voir La méthode du cadre logique de l’ACDI). Le tableau suivant propose une explication de la matrice du cadre logique. Nous reconnaissons que cette méthode peut comporter certaines faiblesses, mais elle demeure un point de départ et une excellente réflexion sur les grands enjeux du projet.

Détails de la matrice du cadre logique

Mémoire d’identification du projet (MIP)

Le MIP est un document de présentation au client et d’approbation, qui regroupe les analyses exposées ci-dessus. Il peut prendre des formes et des noms divers.

Cependant, le MIP composé de six parties et présenté ci-dessous constitue une approche intéressante pour l’ingénieur.e.

• L’origine du projet
  • Cette section devrait fournir les informations suivantes :
    • Situation actuelle – Description de la situation problématique que vit l’entreprise, le problème à résoudre ou l’occasion à saisir
    • Situation désirée – Description en termes concrets des objectifs à atteindre
    • Contraintes à respecter – Règles et obligations à respecter : date de livraison, réglementation, normes de qualité
• La formulation préliminaire du projet, y compris :
  • L’analyse de l’environnement
  • L’analyse des parties prenantes
  • Le cadre logique
• La synthèse des études de préfaisabilité
• Les stratégies de gestion retenues
• Les conclusions et les recommandations
• Les annexes qui comprennent toute l’information supplémentaire jugée nécessaire à la meilleure compréhension du projet par toutes les parties prenantes.

Ressources

LIENS ET RÉFÉRENCES 

• Guide pratique de S&E de projets de l’IFAD
• OLSON, D.L., Information Systems Project Management (2e éd.), New York, Éditions McGraw-Hill/Irwin, 2004
• O’SHAUGHNESSY, W., La faisabilité de projet – Une démarche vers l’efficience et l’efficacité, Trois-Rivières, Les éditions SMG, 1992
• PMI, Guide du Corpus des connaissances en management de projet (3e éd.), Pennsylvania, Éditions PMI, 2004
• WYSOCKI, R.K., Effective Project Management (5e éd.), Indianapolis, Éditions Wiley, 2009
• ACDI