Any Ideas – Pour le chef de projet malin

** Voici un article invité de Thibault PAIRIS ! Excellente lecture ! **

« Votre plus grande erreur sur un projet », c’est le thème que m’a donné Jean-Philippe pour publier un article sur la gestion de projet. En lisant le sujet, me voici redevenu petit garçon, me tordant les mains, les joues rougissantes, en train de réfléchir à avouer ou non ma faute… Dur, dur de se livrer ! Et puis finalement, pas vraiment : savoir avouer ses erreurs, évaluer ce qui est allé de travers, et prendre les mesures pour que ça ne se reproduise pas : c’est aussi ça, être un bon chef de projet.

Le projet dont je vais vous parler était simple : créer une application de saisie de données quotidiennes. Sans entrer dans les détails, l’objectif était de consolider les données de fonctionnement de machines de production situées sur des sites industriels. Cette particularité créait des contraintes importantes :
– les ordinateurs sur sites n’étaient pas connectés à internet ou l’intranet de l’entreprise.
– installer une application n’était pas souhaité (trop d’ordinateurs différents à gérer, pas de support informatique sur place).
– il y avait 200 à 400 valeurs distinctes à entrer tous les jours.
– il fallait que les données saisies soient centralisées dans une base de données de la société, située elle sur l’intranet.

Le coeur du projet était donc un peu paradoxal. Il fallait saisir des données sur des ordinateurs sans connexion réseau, et les transférer sur une base de données connectée… Pour résoudre ce problème, nous avons réfléchi à une solution qui répondait bien aux contraintes du projet :
– créer une interface web déconnectée légère : juste une page web (html) locale à l’ordinateur, avec du code client (javascript) pour des petits contrôles de données basiques.
– cette interface déconnectée permet d’exporter toutes les données dans un fichier de transfert, avec une chaîne de contrôle du fichier pour éviter qu’il ne soit corrompu ou trafiqué.
– le transfert des données est effectué par un moyen physique : clé usb par exemple.
– enfin, les données sont intégrées dans l’intranet, qui permet toutes les fonctionnalités « lourdes » demandées : consolidation mondiale, recherche, export PDF, etc.

Cette architecture comportait des limitations. Par exemple, il ne nous était pas possible d’effectuer beaucoup de contrôles de données. En effet, tout le code était exécuté côté client, donc sur l’ordinateur peu puissant de l’opérateur de saisie. Si nous lancions des contrôles de cohérence complexes, le risque était de faire crasher son navigateur internet.

Face à cette interrogation, le métier s’est voulu très rassurant : « aucun contrôle nécessaire, les utilisateurs savent très bien quoi saisir dans chaque champ !« . Mais il s’agissait de clients internes, c’est-à-dire de départements métiers clients du département informatique. Impossible, donc, de leur faire valider le moindre engagement par écrit : « c’est entre nous, on ne va pas faire de la paperasserie » ! Pour leur permettre de se projeter dans le futur projet, j’ai tout de même pris quelques jours pour créer une maquette de l’interface. Elle était basique : tous les champs, mais des fonctionnalités assez limitées. Le résultat les a emballés ! Pour tout dire, le projet leur paraissait déjà terminé et prêt à être utilisé.

Nous nous lançons donc dans le développement. L’interface déconnectée est un peu rudimentaire, mais les fonctionnalités principales sont déportées sur le site intranet qui reçoit les données. A partir de cet intranet, on peut réaliser à peu près tout ce qui est demandé.

Bref, un projet rondement mené ! Nous sommes donc appelés à défiler dans les couloirs de l’entreprise sous les acclamations des salariés, on nous offre un voyage all-inclusive aux Bahamas et toute mon équipe obtient une augmentation substantielle… euh non, revenons à la réalité : la suite du projet fut à des années-lumières d’un tel dénouement !

Les tests métiers commencent donc : nous leur faisons une démonstration de comment tester et des types de problèmes à rechercher, puis nous les laissons prendre en main l’application. Rapidement, nous recevons des retours liés aux graphismes. Par exemple, nous avons repris en haut à gauche le logo de l’entreprise qui était affiché sur les anciens formulaires papier destinés à saisir ces données. La position de ce logo donne lieu à d’innombrables retours :
– il faut l’aligner avec le titre.
– si on redimensionne la fenêtre, le titre passe en-dessous du logo, alors qu’il devrait rester à droite.
– il faudrait décaler le logo de 5 pixels à gauche, c’est possible ?
– puis, une fois ces ajustements terminés : on a revu l’affichage du rapport avec le responsable du département, il veut utiliser un autre logo.
– et rebelote…
Autre exemple, il est possible d’exporter les données dans un fichier de tableur (Excel). Le nom de ce fichier fait débat :
– faut-il « Nom du site – Rapport – Date au format YYYY-MM-DD » ?
– ou bien « Rapport – Date au format DD/MM/YYYY – Nom du site » ?
– ou bien « Rapport #(numéro du rapport) – Nom du site – Date au format YYYY-MM-DD » ?
Plusieurs semaines passent sur ce type de retour. A chaque fois, nous demandons s’il n’ont pas trouvé des bugs plus importants concernant la sauvegarde des données, la génération du fichier de transfert, l’intégration des données dans l’intranet. La réponse est invariablement que les problèmes déjà remontés sont les seuls et sont critiques pour l’application. Personne ne pourra s’en servir si le logo n’est pas bien aligné !

Après cette première phase apparait un nouveau type de retour. Vous rappelez-vous ce que nous avait dit le client : « aucun contrôle ne sera nécessaire, les utilisateurs savent quoi saisir » ? Finalement, des contrôles étaient nécessaires :
– un contrôle sur la valeur du pH
– un contrôle sur le nombre de décimales
– un contrôle sur la durée totale des opérations qui ne doit pas excéder 24h par jour
– un contrôle sur la cohérence entre les heures saisies et la durée de chaque opération
– un contrôle sur la cohérence du nombre de lignes entre différents tableaux affichés
– etc. …
Après plusieurs mois de développement, le code dynamique sur l’interface déconnectée atteint deux tiers du code total de la page. Certains testeurs remontent alors des problèmes de performances. Exactement ce que nous avions anticipé lors de notre analyse initiale, et un comble pour une interface déconnectée qui devait rester rudimentaire !

Le coup de grâce vient avec les demandes techniquement irréalisables dans l’architecture retenue :
– pouvoir sauver un fichier sur le disque avec le raccourci ctrl+s… ce qui est impossible avec le code javascript d’un ordinateur, puisque accéder aux fichiers de l’ordinateur client serait une faille de sécurité.
– pouvoir générer un rapport PDF complet depuis l’interface déconnectée.
– etc.
Après 6 mois de tests, c’est le moment où il a fallu se résoudre à demander un arbitrage hiérarchique.

Une réunion de concertation inter-départements et de nombreux compromis plus tard, il a été possible de finaliser le projet et le mettre en production. Mis à l’épreuve par des centaines d’opérateurs, des bugs critiques sont ressortis et ont été corrigés. Aujourd’hui, l’application fonctionne parfaitement en production et ses utilisateurs l’apprécient. Cependant, nous n’avons pas encore eu de nouvelles de notre voyage all-inclusive aux Bahamas.

Ce que je retiens de ce projet, c’est qu’il aurait fallu :
– simplifier beaucoup plus la première version de l’application, pour valider le concept dans un premier temps.
– prioriser les tâches afin de privilégier ce qui apporte un gain net à l’entreprise.
– nommer un sponsor du projet, qui soit une personne extérieure au projet et capable d’arbitrer les différends.

Pour en savoir plus, et si vous avez déjà lu deux fois tous les articles de Jean-Philippe, n’hésitez pas à venir me rendre visite sur http://www.rocketprojet.com !

Et si vous recherchez une méthode de gestion de projet facile pour débuter en évitant tous ces problèmes, vous pouvez consulter mon livre paru aux éditions ENI.

– Thibault Pairis

* Le titre est une référence à une citation du surintendant des Finances Sully, au 17e siècle :
« Labourage et pâturage sont les deux mamelles de la France ».
 
Pourquoi ? Parce que la hauteur de vue nécessaire pour gérer un projet vient notamment avec la culture générale 🙂
 
 
 

Avant toute chose, personne ne recrute un chef de projet débutant.

Ce type de poste est d’abord proposé à des personnes travaillant déjà dans l’entreprise et qui ont la confiance du management sur d’autres responsabilités. Par ailleurs, on leur confie le plus souvent des projets secondaires à faibles portée et visibilité, simplement pour limiter le risque.

Donc, si déjà en interne, ils tâchent de limiter le risque avec des personnes connues, pensez-vous qu’ils vont prendre quelqu’un d’extérieur ET débutant ?

Peut-être, s’ils n’ont pas le choix mais ça reste rare.

Alors comment renforcer votre expérience de gestion de projet avant de postuler pour un « vrai » poste de chef de projet ?

La technique secrète des chefs de projets auto-promus

Le moyen de percer comme chef de projet c’est d’utiliser votre poste actuel comme effet de levier.

Devenez un chef de projet au sein du poste que vous occupez.

Même si officiellement ce n’est pas le cas et que ça ne prend pas tout votre temps. N’importe quel poste peut se transformer en un poste avec de la gestion de projet.

En fait, si vous regardez de près votre poste actuel, vous noterez que vous enchaînez déjà les petits projets ou sous-projets sur un projet à plus long terme. La plupart du temps, vous vous managez vous-même, vous êtes responsable de votre périmètre à vous.

Et en prêtant plus d’attention à ce que vous faites, vous pourriez séparer les activités de chef de projet de celles de votre poste « normal ».

Et en pratique, je fais comment ?

Je vous suggère du coup de formaliser vos activités de gestion de projet. Comment ? en suivant une méthodologie même si vous personne ne vous demande de le faire.

Lire la suite »

On me demande souvent ce qu’il faut mettre dans un cahier des charges, dans un document de spécifications, dans un plan projet, …  Et à lire la manière avec laquelle c’est demandé, je devine souvent que c’est un facteur de stress !

• Est-ce que j’ai oublié quelque chose ?
• Est-ce que je dois mettre une section « là-dessus » ?
• Et cette partie-là, on s’en fiche ou pas ?

D’ailleurs, les questions que je reçois reflètent souvent cette incertitude : je dois écrire un document XXX, pouvez-vous m’aider ?

On ne peut pas faire plus vague !

Et, si en plus, ce document est utilisé dans le cadre d’un projet client – prestataire, l’incertitude augmente !

Bien sûr, si vous avez un modèle de document disponible au sein de l’entreprise, vous vous posez moins de questions, mais lisez tout de même la suite, …

Erreur commune : s’arrêter au titre du document

Et souvent, on se cache derrière le titre du document. Sous prétexte que c’est un titre de document connu, on ne pose pas vraiment de questions sur ce qu’il doit contenir. Manquerait plus qu’on passe pour quelqu’un d’incompétent !

Lire la suite »