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 !
« Celui qui pose une question risque cinq minutes d’avoir l’air bête,
celui qui ne pose pas de question restera bête toute sa vie. »
– Proverbe chinois
Le problème avec les titres de document, c’est que selon les entreprises, selon les contextes, selon les projets, selon les clients, selon la culture projet, un type de document avec un certain titre pourra avoir de multiples variantes. Parfois, il peut même y avoir confusion.
Combien de fois j’ai vu un client appeler « dossier de spécifications » ce qu’un prestataire appelait « cahier des charges » ? ça vous rappelle quelque chose ? 🙂
C’est problématique de ne pas être d’accord surtout quand les documents ont une valeur contractuelle et que ça peut vous emmener jusqu’au tribunal !
La question à poser n’est donc pas à propos du titre du document.
La question c’est surtout …
Roulements de tambours …
Quels sont les objectifs du document ?
En fait, ce qui compte ce n’est pas tant le titre du document que son ou ses objectifs.
Et oui, à quoi il va servir ce document ?
Oui je sais ça paraît stupide, mais il y a beau y avoir un paragraphe « Objectifs du document » dans l’introduction de beaucoup de documents que j’ai pu voir passer, les gens ne le remplissent que parce qu’il faut le remplir et ça fait partie du « blabla » général que personne ne lit. Ou alors s’il est bien rédigé, il n’est pas respecté.
Je caricature et je généralise … peut-être …
Cela ne vous aide pas ? Prenons deux exemples pour illustrer.
Exemple 1 : Le cahier des charges
A quoi cela va-t-il servir ? Quel est l’objectif du document ?
Recueillir les besoins des utilisateurs.
C’est un peu court jeune homme …
Poussons un peu plus :
Recueillir les besoins des utilisateurs afin de les présenter à un prestataire pour obtenir une proposition commerciale pour réaliser la solution technique répondant à ces besoins.
Il y a un peu plus de perspective, n’est-ce pas ?
Cela veut dire indirectement que quelqu’un d’extérieur au métier va devoir comprendre ce cahier des charges. Autrement dit, le vocabulaire devra être adapté ou expliqué via un glossaire, une présentation de l’existant sera nécessaire pour savoir d’où on part, et puisque le prestataire devra proposer une solution technique, autant lui présenter les contraintes du département informatique, en rapport avec ces besoins.
Vous noterez qu’à mesure que vous comprenez à quoi va servir le document, vous comprenez mieux ce qu’il doit contenir.
Exemple 2 : Le plan projet
A quoi cela va-t-il servir ? Quel est l’objectif du document ?
Nous avons besoin de connaître le planning et les risques associés au projet.
Et si on creusait un peu plus ? Qui va se servir de ce planning ?
Le département informatique du client et les 4 prestataires impliqués.
Ah, intéressant, ça se précise.
Ce que je retiens pour l’instant, c’est que le planning va devoir mettre en évidence les points d’interaction avec le département informatique du client et les 4 prestataires, autrement dit fourniture de pré-requis à certaines dates (exemple: quelle couleur pour la voiture monsieur le Client ?), attente de livrables intermédiaires à d’autres (livraison des pots de peinture avec la bonne couleur), histoire que tout le monde sache ce qu’il a à faire et pour quand.
Du coup, ce planning ne va pas nécessairement contenir le détail de qui fait quoi dans VOTRE équipe. Ou en tout cas, la vue du planning ne présentera pas cela.
Notez que si ça avait été à destination du client ou du comité de direction, le planning aurait été présenté différemment. J’explique aux personnes que je coache qu’il est crucial de préparer un planning spécifique (ou du moins une vue spécifique) pour chaque partie prenante et de communiquer dessus proprement pour bien piloter son projet jusqu’au bout.
Bien sûr ces exemples ne sont que des … exemples, à vous d’adapter en fonction des réponses que vous obtenez par rapport aux objectifs du document demandé.
La question des documents, de leurs objectifs et du coup de ce qu’ils contiennent est une source majeure de malentendus sur les projets, ne sous-estimez pas cet aspect crucial dans votre gestion de projet.
Rattraper un « Aaaah mais je croyais que … » est toujours plus coûteux que de poser quelques questions au préalable. D’autant que parfois, on se rend compte que le document ne servirait à rien …
Cela répond-t-il à la question ? 🙂
Très intéressant ! C’est évident que la préparation des documents projets a son importance: je rajouterai un point qui très souvent aide à la compréhension du contenu et évite des malentendus.
C’est l’utilisation d’exemples réels et concrets pour clarifier l’information qu’on veut passer.
Merci pour le partage.
KJ