Le chef de projet peut parfois tomber dans des pièges lorsqu’il gère son projet. Qu'il soit expérimenté ou junior, certains réflexes peuvent amener à faire des erreurs.
Voici 5 erreurs classiques en gestion de projet.
Cela peut paraître pourtant évident, mais commencer son projet en créant un planning de tâches est une erreur. En effet, avant de définir des tâches, il est bon de définir à quoi serviront ces tâches. Et elles serviront à créer un produit, le produit du projet. La première chose à faire n’est donc pas de définir le travail à faire, mais le produit et ses livrables.
La première étape d'un projet consiste par conséquent à en formuler les grandes lignes. Et on pourra faire cela par l'intermédiaire d'une charte projet, ou d'un énoncé de projet. Dans cette phase, on va notamment cadrer notre projet en clarifiant pourquoi on le fait, et ce qui est attendu. Cela introduira le travail permettant de détailler le produit du projet en le découpant en plusieurs sous-produits ou livrables. Et ensuite, on pourra commencer à réfléchir aux activités.
Ce séquencement est finalement logique : avant de planifier la construction des murs d'une maison, je vais déjà m'assurer qu'il s'agit bien d'une maison qui est attendu et pas d'un garage. Dis comme cela, c'est évident. Donc je ne vais pas ouvrir mon MSProject ou la page "Activités" d'un projet sous Gouti sans avoir auparavant défini une charte projet et des livrables.
Impliquer les utilisateurs en phase de validation n’est pas une erreur. Mais les impliquer seulement à partir de la phase de validation est une erreur.
Trop souvent les utilisateurs finaux sont sollicités trop tardivement dans les projets. C'est dès la phase de conception, et notamment la définition des livrables qu'ils doivent être impliqués. En effet, ce sont au final eux qui valideront le produit. Donc c'est avec eux qu'il faut définir les livrables et leur critère d'acceptation.
Certains diront que c'est le client qui valide. Certes, mais le client (si il n'est pas aussi l'utilisateur) demandera à ses utilisateurs finaux de vérifier avant de donner sa validation.
Même si vous avez une liste de livrables claire avec des critères d'acceptation, cela ne suffira pas à garantir la validation des livrables. Car c'est bien l'utilisateur qui aura le dernier mot pour valider que le produit réponde à son besoin. Et donc, en intégrant l'utilisateur lors de la définition des critères d'acceptation, on augmente considérablement nos chances d'avoir les livrables rapidement validés.
Dans le monde merveilleux de la gestion de projet : je définis mon projet, je le réalise, je le livre.
Mais malheureusement, le monde merveilleux de la gestion de projets n'existe pas. Il est quasiment certain que durant la réalisation du projet, des événements, des nouveaux besoins, des contraintes apparaissent et nécessitent l'intégration de changements. Cela veut dire qu'il faut, dès le démarrage du projet, définir les processus qui permettront de gérer les demandes de changements. Une demande de changement ne veut pas dire un changement. Une demande se qualifie, s'analyse, se décide. Et en fonction, on intégrera ou non les changements.
Si vous ne mettez pas ce processus en place dès le début, cela sera très compliqué de le définir en cours de projet car à ce moment-là, vous serez dans l'urgence. A noter, une fiche simple et rapide à remplir est disponible dans Gouti pour la gestion des demandes de changement.
Un planning peut vite devenir complexe. Par sa multitude de tâches, les relations entre tâches, les durées, un planning détaillé va devenir difficilement lisible. Le planning détaillé est d'abord le document de travail du chef de projet. Pour la communication du planning vers le client, l'utilisateur, le manager, il faut savoir synthétiser en produisant un planning lisible et clair : un macro-planning.
Ce macro-planning doit montrer les tâches principales, les principaux jalons. Si possible, on fera une version graphique qui tient sur une page.
Il ne faut pas sous-estimer l'impact d'une mauvaise communication par un planning dans une version trop complexe. Un chef de projet doit savoir adapter sa communication à son interlocuteur. Le macro-planning est un de ces éléments d'adaptation. Bien que graphique, même un GANTT peut être illisible.
Une diapositive PowerPoint peut par exemple être la solution. Vous trouverez aussi sur Gouti un composant permettant de créer automatiquement un macro-planning.
Le risque. La gestion de risques ... Avant même de commencer, on peut penser qu'on va rentrer dans un processus compliqué, lourd, administratif, voir inutile. Et cela peut être le cas si on ne sait pas adapter ce processus à la taille de son projet. J'ai écrit un article sur le site de CG Project Management expliquant les grandes lignes pour avoir une gestion de risques efficace.
Il est important de comprendre qu'une gestion de risques adaptée à son projet est un atout important pour le succès du projet. Cela améliore l'anticipation, la communication, la prise de décision. Cette gestion de risques est un processus qui se déroule sur tout le long du projet. Le projet évolue, les risques également.
Pour commencer, vous pouvez travailler avec un simple tableur. L'important est de ne pas travailler seul sur ce sujet, c'est un travail qui doit être réalisé avec toutes les parties prenantes du projet. Et il faudra régulièrement refaire des revues des risques.
Evidemment, vous trouverez sur Gouti une solution de gestion de risques.
-----
Christian Gutekunst
Le blog de Gouti