Livrable projet : 10 manières de vous tirer une balle dans le pied

Le projet est quasiment terminé, vous êtes bien au niveau de vos charges projet, vous allez finir dans les délais, bref ça promet une belle fin de projet ! La mise en production se passe bien, le client est content, il vous le fait savoir et puis finit par vous poser la question qui tue : quand est-ce que vous pensez pouvoir livrer le reste de la documentation ?

Petit moment de solitude .. le reste de la documentation ? vous retournez jeter un oeil à la proposition commerciale et vous vous effondrez un peu plus dans votre fauteuil à chaque fois que vous voyez un paragraphe mentionner un livrable de plus .. Ca vous rappelle quelque chose ?

Quelles sont les erreurs à éviter ?

1. Ne pas mettre de tableau des livrables

Faire un tableau récapitulatif des livrables dans la proposition commerciale permet de clarifier le périmètre du projet. Ca permet également de confronter chaque livrable avec un élément du tableau du chiffrage, pour vérifier que chacun des documents à livrer a été chiffré. Relisez bien la proposition commerciale pour extraire tous les livrables dont il est question, cela vous évitera des surprises ensuite.

2. Ne pas spécifier la langue des livrables

Mieux vaut préciser la langue des livrables dans la proposition commerciale, c’est une petite phrase, ça ne coûte rien. Parfois, plusieurs langues peuvent être demandées, à vous de chiffrer en conséquence selon les compétences disponibles. Le commercial peut vous aider pour ce genre de demande car il est sensé connaître la ou les langues de travail du client.

Par extension, et sur une remarque d’un lecteur, pensez aux devises, aux systèmes de mesure, de poids … Selon les projets / clients, c’est plus ou moins évident, mais restez sur vos gardes.

3. Ne pas évaluer le niveau de détails

Selon les contextes, la documentation nécessitera différents niveaux de détails : si les destinataires sont des profils techniques, vous irez moins dans le détail des commandes à exécuter pour une documentation d’installation par exemple ; si vos interlocuteurs ne sont pas du tout techniques mais vont devoir mettre les mains dans le cambouis, prévoyez une documentation pas à pas. Vous vous en doutez la charge ne sera pas la même.

4. Ne pas se mettre d’accord sur le contenu

Si on n’est pas familier avec les titres de livrables demandés par le client (parfois, lui-même ne sait pas ce que c’est, il suit juste la procédure documentaire de l’entreprise ..), mieux vaut demander un modèle ou proposer une trame ou un plan du document dès la phase d’avant-vente pour être sûr de savoir de quoi on parle et pouvoir chiffrer et livrer en conséquence.

5. Sous-estimer la documentation utilisateur

Une documentation utilisateur complète d’une application web spécifique peut devenir une tâche très chronophage. Imaginez une doc utilisateur pour Facebook, Linkedin ou Viadeo ? Si vous pouvez la sortir du périmètre, c’est une solution possible, sinon demandez le niveau de détail requis (faut-il descendre jusqu’au niveau de clic d’un formulaire pour les utilisateurs finaux ?) et prévoyez la charge en conséquence. Un compromis peut-être également de fournir une trame avec impressions écran et laisser le client rédiger le contenu par exemple.

6. Travailler sur des documents existants

Cela peut-être risqué de reprendre une documentation existante. Comment le client va-t-il valider / recetter le document ? va-t-il faire la part des choses entre ce qui existait et ce que vous avez ajouté ? Méfiez-vous du format de document qui peut être un vrai cauchemar et méfiez-vous du suivi des modifications si vous ne le maîtrisez pas. Enfin et surtout assurez-vous que le document ne continue pas à vivre côté client pendant le projet et que vous vous retrouviez à devoir fusionner votre nouvelle version avec la nouvelle version du client ..

7. Ne pas fournir une documentation suffisante

Pour que le client soit autonome en phase de garantie voire de support ensuite, mieux vaut lui proposer et lui livrer un minimum de documentation : une documentation de l’existant (comment c’est fait), une documentation de maintenance (opérations courantes d’exploitation) et une documentation « en cas de problème » (que faire en cas de désastre ..) me paraissent un minimum. A adapter au contexte bien évidemment mais plus il sera autonome, plus vous serez tranquille.

8. Ne pas faire valider la documentation

Dans le propre intérêt du client, c’est mieux s’il valide la documentation pour vérifier qu’elle est utile, que la documentation d’installation permet bien de réinstaller par exemple et qu’elle est suffisamment complète pour son niveau de connaissance. Et pour valider, rien ne vaut la pratique ! Faites installer l’environnement de recette par le client par exemple pour qu’il valide la documentation et monte en compétence sur le livrable du projet. Ce n’est pas le jour où il en aura vraiment besoin qu’il faudra qu’il vérifie qu’elle contient ce qu’il faut.

9. Ne pas tenir compte des allers-retours

Une charge de relecture / prise en compte de modifications est toujours à considérer pour un livrable documentaire. Cela peut être parce que la personne qui va la rédiger n’est pas aguerrie à l’exercice de documentation et qu’il vous faudra y revenir à plusieurs fois pour arriver au résultat. Cela peut être également parce que le client va être tatillon / exigeant sur la documentation ou que vous n’aurez pas suivi les conseils ci-dessus ..

10. Ne pas gérer les versions

Mettez-vous d’accord avec vos équipes, collègues, fournisseurs, clients sur un système de version pour les documents. Quand on est tout seul à gérer la documentation, on peut s’en sortir, à partir de 2, gare aux cafouillages .. Versions 1.1, 1.2, 1.3, éventuellement avec un 3e niveau pour gérer les sous-versions internes avant livraison, à vous de voir ce qui vous convient du moment que ça marche.

J’ai pensé à  un dernier conseil juste avant de publier : pensez à archiver votre documentation. Cela vous permettra de créer des modèles pour de futurs projets ou dépanner un client qui, lui, n’a pas archivé ..

J’allais vous donner l’exemple de la NASA pour finir. Elle n’aurait plus été capable de créer la fusée Saturn V qui a envoyé les premiers hommes sur la lune car la documentation aurait été perdue .. Mais après vérification, il s’agissait de rumeurs .. Dommage, j’adorais l’exemple ! Mais a priori tout a été stocké sur micro-films. Bref, ce n’est pas parce que vous n’êtes pas à la NASA que vous ne devriez pas archiver ! 😉

Et vous ? quels sont vos réflexes en matière de documentation ?

Pour écouter le podcast :

ou télécharger la version mp3 : AnyIdeas.net-livrables-documentaires-10-manieres-de-vous-tirer-une-balle-dans-le-pied.mp3

8 réflexions au sujet de “Livrable projet : 10 manières de vous tirer une balle dans le pied”

  1. Juste une petite pierre supplémentaire :
    Aujourd’hui si l’on n’est plus à l’aire de la NASA, les documents sont souvent livrés au format numérique avec CD ou DVD. Ne pas oublier de faire noter dans l’offre les logiciels et versions de la documentation.

    Je me souviens d’un grand blanc dans l’équipe projet quand il a fallu convertir les fichiers du design dans un autre soft.

    Par extension, le langage : Pas facile de traduire du Francais en Hindoux …

    Répondre
    • Merci Thierry pour ta pierre ! tu as tout à fait raison, le format de document est à préciser pour éviter bien des problèmes, d’autant qu’il peut y avoir des incompatibilités entre les versions d’un même logiciel ..

      Répondre
  2. Ahh l’épineuse question de la documentation ! Est-ce le parent pauvre de la gestion de projet ?

    C’est un peu comme le cailloux dans la chaussure : petit, on n’y fait pas attention, mais il a un pouvoir de nuisance certain !

    Super de poser le cadre dans ton article des erreurs à éviter avec la documentation. Autant passer un minimum de temps en début de projet sur le sujet. Cela évite des charges non prévues à la fin.

    Répondre
  3. Super article! Merci

    3 points à ne pas négliger
    1/ La proposition technique doit lister les livrables.
    2/ lors de la réunion de lancement du projet on reliste les livrables et on valide le système de versionnage, la langue etc (
    3/ des que possible, le CP livre les modèles des différentes documentations au moins le client ne sera pas surpris le jour de la livraison finale.

    Répondre
  4. Je rédige les documents avec des champs comme [Reference], ou http://[AdresseSiteClient]/…, ou //[ServeurProjet]/Documentation/…

    Puis je rédige un document annexe avec les valeurs :
    [Reference] = c:\program files\LeDossier
    [AdresseSiteClient] = http://www.toto.com »
    [ServeurProjet] = FRDOC123
    ainsi la documentation ne devient pas obsolète dès que lorsqu’on renomme ou déplace des objets dans la vie de l’application !

    Répondre

Laisser un commentaire