L'essentiel de la gestion de projet
Par William Porret, directeur associé du cabinet de conseil en management Enora Consulting
01/10/11 - Archimag
Le point de départ d'un projet est trop souvent un outil informatique qu'un collaborateur a vu dans un magazine, une autre organisation ou un salon et qu'il souhaite voir installer au sein de sa propre organisation, convaincu qu'il s'agit de LA solution. Or, pour être couronné de succès, un projet doit d'abord partir d'un ou plusieurs besoins métier auxquels certains outils informatiques peuvent répondre. Implémenter un logiciel constitue aujourd'hui un vrai challenge, avec dans certains cas des enjeux majeurs pour l'entreprise. Il est donc nécessaire que cette implémentation soit menée de la même façon que tout autre projet, en respectant des étapes-clés incontournables :
Cette première réunion consiste à cadrer le projet : validation de son périmètre, mise en place de l'équipe, définition du planning et du budget alloué. L'étape de lancement permet de s'assurer que tous les acteurs indispensables à la conduite du projet seront présents et disponibles pour le mener à bien. L'équipe doit, dans la mesure du possible, rester la même du début à la fin afin d'éviter la perte d'information.
L'un des facteurs-clés du succès du projet est l'identification d'un sponsor du projet, qui doit être à un niveau hiérarchique suffisamment élevé pour être reconnu. Ce sponsor n'intervient pas forcément au niveau opérationnel, en revanche son rôle est primordial dans la communication menée autour du projet.
Cette étape de cadrage permet également d'identifier les freins/risques inhérents au projet et d'élaborer un plan de contournement associé pour chacun de ses freins/risques. Lors de la réunion de lancement, une première action opérationnelle est menée à travers la mise en place des structures projets :
Analyse de l'existant
C'est une étape de compréhension de l'environnement aussi bien humain, technique qu'organisationnel. Elle permet d'identifier les points de résistance au changement et les collaborateurs qui pourront être les référents auprès de leurs collègues.
L'analyse de l'existant est une communication bidirectionnelle qui permet à la fois de communiquer sur le projet et de récupérer les informations essentielles au projet.
Cette étape peut être courte, notamment lors d'un projet de réinformatisation. Elle reste néanmoins importante pour identifier très clairement le périmètre des fonctionnalités existantes dans l'outil actuel.
Bien menée, l'analyse de l'existant apporte une cartographie des éléments dans un environnement plus large que le projet afin de mesurer l'intégration du projet dans l'environnement complet de l'organisation.
Analyse des besoins
Cette étape se déroule parfois en même temps que l'étude de l'existant, par exemple pour un projet de moindre envergure. Le risque encouru est alors de sous-estimer l'étendue de l'environnement impacté par le projet et de se réduire à informatiser l'existant. Or, le besoin ne se résume pas à informatiser les processus existants, mais il répond à un objectif global de l'organisation, décliné en fonctionnalités essentielles.
Le livrable de l'analyse des besoins est un document de référence, appelé cahier des charges, qui permettra de trouver la solution adéquate à mettre en oeuvre, de prévoir un développement informatique ou de sélectionner un logiciel du marché. C'est ce cahier des charges qui doit être repris dans le CCTP d'un appel d'offres. Les différents thèmes fonctionnels traités pourront être repris dans la décomposition du prix global et forfaitaire. Dans le cas d'un appel d'offres, il faut également veiller à d'autres préoccupations telles que l'allotissement, la possibilité d'options ou de tranches conditionnelles ou encore de bons de commande pour la maintenance, par exemple.
Le cahier des charges présente les besoins à un niveau macroscopique. Lorsque la solution à mettre en oeuvre a été choisie, ces besoins doivent être détaillés dans les spécifications.
Selon l'importance des projets, il est souvent nécessaire de rédiger, d'une part, des spécifications fonctionnelles qui présenteront les besoins au format de la MOA compréhensible par les utilisateurs et, d'autre part, des spécifications techniques rédigées par la MOE qui traduisent les besoins en termes informatiques, soit pour un développement, soit pour un paramétrage de logiciel.
Conduite du changement
Sur la base de l'expression des besoins, la MOE va développer et/ou paramétrer les outils informatiques nécessaires. Durant cette période, la MOA gère le changement auprès des utilisateurs. Ces changements peuvent toucher l'organisation, les processus, les habitudes de travail et bien sûr les outils informatiques utilisés. Au fur et à mesure de la réalisation des développements et paramétrages, la MOA communique aux utilisateurs les nouveaux processus et l'avancée du planning. Cette phase, très souvent négligée, est pourtant clé dans la conduite du projet, car elle garantit l'adhésion des collaborateurs au nouvel outil mis à leur disposition. La conduite du changement permet de lever les éventuelles réticences au changement et garantit ainsi la réussite du projet.
Recette
La recette est une étape qui permet de vérifier que l'outil développé/paramétré répond bien aux besoins exprimés. Une recette consiste à tester les fonctionnalités de l'outil en s'appuyant sur des cas concrets qui correspondent au travail quotidien des utilisateurs. La recette comprend une partie technique réalisée par la MOE et une partie fonctionnelle réalisée pat la MOA. La recette peut être décomposée en une ou plusieurs sous-recettes en fonction de l'importance du projet, des fonctionnalités de l'outil ou des utilisateurs concernés.
Concrètement, la recette de déroule de la façon suivante :
Formation
La formation des utilisateurs finaux est essentielle car elle permet de resituer le contexte du projet et de répondre à leurs interrogations. Cette période peut être longue et représenter une charge importante du projet, elle doit donc absolument être planifiée en amont. Les interlocuteurs référents, identifiés en amont lors de l'analyse de l'existant, doivent bénéficier d'une formation poussée de manière à devenir eux-mêmes formateurs auprès des autres utilisateurs. Les référents seront les porte-parole du projet. Les utilisateurs ayant des doutes sur les processus ou l'outil pourront se reposer sur ces référents pour poser des questions et renforcer leurs compétences.
Mise en production
Le jour de la mise à disposition du logiciel, il est nécessaire de prévoir la totale disponibilité de l'équipe projet afin de répondre aux interrogations des utilisateurs finaux et de leur porter assistance si besoin. Le déploiement peut se faire en plusieurs phases ou en une seule fois. Un support immédiat aux utilisateurs dans les premiers jours de mise en production doit être mis en place. Une communication de lancement et de fin de projet est à prévoir pour acter le fait que le projet est terminé et que les nouveaux processus de travail sont incontournables. Il est possible de prévoir des formations supplémentaires lors de cette phase de mise en production, l'idéal étant de faire réaliser ces formations par les référents. Enfin, une revue post-projet permet à l'organisation de disposer d'un retour d'expérience pour améliorer la gestion de ses futurs projets. Cette revue est également le moment idéal pour identifier des évolutions possibles du projet.
Par William Porret, directeur associé du cabinet de conseil en management Enora Consulting
01/10/11 - Archimag
Le point de départ d'un projet est trop souvent un outil informatique qu'un collaborateur a vu dans un magazine, une autre organisation ou un salon et qu'il souhaite voir installer au sein de sa propre organisation, convaincu qu'il s'agit de LA solution. Or, pour être couronné de succès, un projet doit d'abord partir d'un ou plusieurs besoins métier auxquels certains outils informatiques peuvent répondre. Implémenter un logiciel constitue aujourd'hui un vrai challenge, avec dans certains cas des enjeux majeurs pour l'entreprise. Il est donc nécessaire que cette implémentation soit menée de la même façon que tout autre projet, en respectant des étapes-clés incontournables :
- Réunion de lancement
- Analyse de l'existant
- Analyse des besoins
- Conduite du changement
- Recette
- Formation
- Mise en production
Cette première réunion consiste à cadrer le projet : validation de son périmètre, mise en place de l'équipe, définition du planning et du budget alloué. L'étape de lancement permet de s'assurer que tous les acteurs indispensables à la conduite du projet seront présents et disponibles pour le mener à bien. L'équipe doit, dans la mesure du possible, rester la même du début à la fin afin d'éviter la perte d'information.
L'un des facteurs-clés du succès du projet est l'identification d'un sponsor du projet, qui doit être à un niveau hiérarchique suffisamment élevé pour être reconnu. Ce sponsor n'intervient pas forcément au niveau opérationnel, en revanche son rôle est primordial dans la communication menée autour du projet.
Cette étape de cadrage permet également d'identifier les freins/risques inhérents au projet et d'élaborer un plan de contournement associé pour chacun de ses freins/risques. Lors de la réunion de lancement, une première action opérationnelle est menée à travers la mise en place des structures projets :
- le chef de projet qui coordonne l'ensemble des intervenants est désigné
- le planning et le budget sont définis et seront suivis tout au long du projet et remontés en comité de projet ou de pilotage suivant le niveau d'alerte associé
- le comité de pilotage qui valide les propositions et orientations en termes de périmètre, budget et planning est constitué
- le comité de projet qui globalise les actions des équipes projet et propose des orientations projets est désigné
- la ou les équipes projet qui réalisent les actions prévues au planning sont sollicitées
Analyse de l'existant
C'est une étape de compréhension de l'environnement aussi bien humain, technique qu'organisationnel. Elle permet d'identifier les points de résistance au changement et les collaborateurs qui pourront être les référents auprès de leurs collègues.
L'analyse de l'existant est une communication bidirectionnelle qui permet à la fois de communiquer sur le projet et de récupérer les informations essentielles au projet.
Cette étape peut être courte, notamment lors d'un projet de réinformatisation. Elle reste néanmoins importante pour identifier très clairement le périmètre des fonctionnalités existantes dans l'outil actuel.
Bien menée, l'analyse de l'existant apporte une cartographie des éléments dans un environnement plus large que le projet afin de mesurer l'intégration du projet dans l'environnement complet de l'organisation.
Analyse des besoins
Cette étape se déroule parfois en même temps que l'étude de l'existant, par exemple pour un projet de moindre envergure. Le risque encouru est alors de sous-estimer l'étendue de l'environnement impacté par le projet et de se réduire à informatiser l'existant. Or, le besoin ne se résume pas à informatiser les processus existants, mais il répond à un objectif global de l'organisation, décliné en fonctionnalités essentielles.
Le livrable de l'analyse des besoins est un document de référence, appelé cahier des charges, qui permettra de trouver la solution adéquate à mettre en oeuvre, de prévoir un développement informatique ou de sélectionner un logiciel du marché. C'est ce cahier des charges qui doit être repris dans le CCTP d'un appel d'offres. Les différents thèmes fonctionnels traités pourront être repris dans la décomposition du prix global et forfaitaire. Dans le cas d'un appel d'offres, il faut également veiller à d'autres préoccupations telles que l'allotissement, la possibilité d'options ou de tranches conditionnelles ou encore de bons de commande pour la maintenance, par exemple.
Le cahier des charges présente les besoins à un niveau macroscopique. Lorsque la solution à mettre en oeuvre a été choisie, ces besoins doivent être détaillés dans les spécifications.
Selon l'importance des projets, il est souvent nécessaire de rédiger, d'une part, des spécifications fonctionnelles qui présenteront les besoins au format de la MOA compréhensible par les utilisateurs et, d'autre part, des spécifications techniques rédigées par la MOE qui traduisent les besoins en termes informatiques, soit pour un développement, soit pour un paramétrage de logiciel.
Conduite du changement
Sur la base de l'expression des besoins, la MOE va développer et/ou paramétrer les outils informatiques nécessaires. Durant cette période, la MOA gère le changement auprès des utilisateurs. Ces changements peuvent toucher l'organisation, les processus, les habitudes de travail et bien sûr les outils informatiques utilisés. Au fur et à mesure de la réalisation des développements et paramétrages, la MOA communique aux utilisateurs les nouveaux processus et l'avancée du planning. Cette phase, très souvent négligée, est pourtant clé dans la conduite du projet, car elle garantit l'adhésion des collaborateurs au nouvel outil mis à leur disposition. La conduite du changement permet de lever les éventuelles réticences au changement et garantit ainsi la réussite du projet.
Recette
La recette est une étape qui permet de vérifier que l'outil développé/paramétré répond bien aux besoins exprimés. Une recette consiste à tester les fonctionnalités de l'outil en s'appuyant sur des cas concrets qui correspondent au travail quotidien des utilisateurs. La recette comprend une partie technique réalisée par la MOE et une partie fonctionnelle réalisée pat la MOA. La recette peut être décomposée en une ou plusieurs sous-recettes en fonction de l'importance du projet, des fonctionnalités de l'outil ou des utilisateurs concernés.
Concrètement, la recette de déroule de la façon suivante :
- la MOE livre les fonctionnalités développées/paramétrées
- la MOA teste ces fonctionnalités et remonte des fiches de non-conformité à la MOE
- la MOE reprend alors les développements/paramétrages et relivre les fonctionnalités qui devront être de nouveau testées et ainsi de suite jusqu'à ce qu'un procès verbal de recette valide la conformité de l'outil avec les besoins des utilisateurs.
Formation
La formation des utilisateurs finaux est essentielle car elle permet de resituer le contexte du projet et de répondre à leurs interrogations. Cette période peut être longue et représenter une charge importante du projet, elle doit donc absolument être planifiée en amont. Les interlocuteurs référents, identifiés en amont lors de l'analyse de l'existant, doivent bénéficier d'une formation poussée de manière à devenir eux-mêmes formateurs auprès des autres utilisateurs. Les référents seront les porte-parole du projet. Les utilisateurs ayant des doutes sur les processus ou l'outil pourront se reposer sur ces référents pour poser des questions et renforcer leurs compétences.
Mise en production
Le jour de la mise à disposition du logiciel, il est nécessaire de prévoir la totale disponibilité de l'équipe projet afin de répondre aux interrogations des utilisateurs finaux et de leur porter assistance si besoin. Le déploiement peut se faire en plusieurs phases ou en une seule fois. Un support immédiat aux utilisateurs dans les premiers jours de mise en production doit être mis en place. Une communication de lancement et de fin de projet est à prévoir pour acter le fait que le projet est terminé et que les nouveaux processus de travail sont incontournables. Il est possible de prévoir des formations supplémentaires lors de cette phase de mise en production, l'idéal étant de faire réaliser ces formations par les référents. Enfin, une revue post-projet permet à l'organisation de disposer d'un retour d'expérience pour améliorer la gestion de ses futurs projets. Cette revue est également le moment idéal pour identifier des évolutions possibles du projet.
©2009 - tous droits réservés