Pourquoi les chefs de projets doivent-ils comprendre les contrats ?

Article originalement publié sous le tite « Why Project Managers Need to Understand Contracts » sur PM Today.

Tiffany Kemp est l’auteure de Deal Makers – how intelligent use of contracts can help you sell more and deliver better. Fondatrice et directrice exécutive chez Devant.co.uk, elle a lancé le site web FreeContractAdvice.com  sur lequel elle dispense gratuitement des conseils et partage son expérience sur comment bien préparer et rédiger un contrat.

Dans cet article, le focus est placé sur les chefs de projets et les contrats.

La vue traditionnelle du contrat chez les chefs de projet peut être brièvement récapitulée par : « Si vous devez sortir le contrat du tiroir, c’est que le projet va vraiment mal. »

Cette perspective associe les contrats à l’échec, aux conflits, à la fin d’une relation commerciale et au début d’un coûteux litige. Elle incarne l’approche du  » contrat comme une arme » où il est utilisé soit pour taper sur l’autre partie, soit défendre votre propre camp, en cas de problèmes. En partant de là, les chefs de projet n’ont pas plus besoin de comprendre des contrats que de comprendre comment survivre dans un monde post-apocalyptique. Parce que, franchement, à l’instant où le contrat sort du tiroir, c’est déjà fini de toute façon.

Mais il y a une meilleure façon d’utiliser nos contrats, pour qu’ils ajoutent la valeur à nos relations commerciales plutôt que de seulement occuper de l’espace dans un meuble d’archivage.

Le « manuel de l’utilisateur pour votre relation commerciale »

Imaginez créer un plan de projet complet et incluant votre diagramme de Gantt, la structure de gouvernance du projet et ses jalons de livraison et ensuite le mettre de côté dans une armoire, pour ne jamais être le regarder de nouveau. Vous vous frayez un chemin dans le projet, espérant faire les bonnes choses aux bons moments, avec le bon standard, en sachant que vous n’aurez pas l’opportunité de regarder le plan de projet de nouveau à moins que vous ne soyez partis si spectaculairement hors-piste que le client ait convoqué ses avocats.

Ce n’est pas une image très confortable, n’est-ce pas ?

Et pourtant, lorsqu’il s’agit du contrat par rapport auquel nous supposons que votre plan de projet va délivrer, c’est exactement ce que nous faisons. Nous dépensons des semaines ou des mois à négocier chaque détail du contrat et ensuite, une fois qu’il est signé, il est mis sous une cloche en verre sur laquelle est inscrit : « En cas d’urgence, briser la vitre ».

Le contrat devrait fournir le cadre pour le développement et la livraison de votre plan de projet. Le contrat devrait exposer clairement :

Si nous regardons chacun de ces trois triangles tout à tour, vous verrez que l’essentiel des contrats commerciaux vous est beaucoup moins étranger que vous pourriez le penser.

 « qui fait quoi, quand ? »

Ce premier triangle nous dit ce que nous devrions livrer et ce dont nous avons besoin du client pour le faire avec succès. Ceci nous donne la matière première pour le diagramme de Gantt, l’échéancier de livraison et les dépendances sur le client qui sont si essentielles pour notre planification de projet.

C’est aussi le domaine où les problèmes ont le plus de probabilité de surgir au cours du projet. Les désaccords sur le contenu (la portée/le périmètre) sont une source majeure de conflits commerciaux et une zone de stress significatif pour beaucoup de chefs de projet. Pourquoi ? Parce que nous avons une vue fondamentalement différente du contenu selon que nous soyons côté client ou côté vendeur. Les clients ont tendance à voir tous les changements de périmètre comme ‘des clarifications’, tandis que les vendeurs ont tendance à les voir comme ‘des changements’ et donc facturables.

Dans le contrat BAA T5 sur le nouvel aérogare d’Heathrow, BAA a dès le départ reconnu ce problème et s’y est attaqué d’une façon nouvelle. Plutôt que d’assumer tout resterait statique, ils ont accepté que le changement était inévitable. Ils ont créé une structure qui a assuré aux sous-traitants qu’ils seraient payés pour leur temps et matériels tant pour les ‘changements’ que pour les clarifications’, mais ne feraient du bénéfice que sur les ‘changements’. Bien que ceci signifiait que BAA et le sous-traitant devaient toujours trouver un accord pour dire si quelque chose était un changement ou une clarification, cela réduisait significativement le risque pour le sous-traitant et changeait fondamentalement le ton sur la gestion des changements dans le projet.

En tant que un chef de projet, comprendre a) ce qu’est le contenu et b) comment gérer le changement est clé à votre succès. Avoir ceci clairement documenté dans votre contrat, de façon pratique et réalisable, vous donne confiance pour faire respecter une bonne gestion des changements.

Qu’entends-je par ‘bonne’ gestion des changements ?

Je veux dire être clair, transparent et cohérent pour que votre client comprenne que vous êtes heureux de faire quoi qu’ils demandent – pourvu qu’ils en acceptent le coût, le risque, le contenu et/ou les implications sur les délais. Ceci pourrait signifier devoir  retarder d’autres livrables pour trouver une petite place pour quelques fonctionnalités supplémentaires. Cela pourrait signifier un coût additionnel. Ou cela pourrait simplement rendre le projet dans son ensemble plus risqué, auquel cas vous voudrez que le client accepte tout ou partie de ce risque supplémentaire.

Le modèle T5 était si réussi qu’il a été adopté comme la base de contrat de sous-traitance sur la construction du Parc Olympique. Dans ce contexte, il a aussi livré quelques résultats novateurs en termes de durabilité et l’utilisation de matériels qui n’auraient tout simplement pas été réalisables sous le modèle habituel qui consiste à faire porter tous les risques aux fournisseurs.

‘ Quand le paiement se produit-il ? ‘

En tant que un chef de projet, vous pourriez ne pas être terriblement concentrés sur le paiement en soi. Mais le passage de vos jalons de livraison sera tout en haut de votre liste de priorités ! Généralement, les deux sont liés et chaque jalon va probablement être associé à un paiement partiel correspondant qui permet le financement du projet au fil de son exécution.

De votre perspective, regardez le contrat pour voir s’il explique clairement comment vous saurez quand un jalon de livraison a été passé.

Les jalons devraient être clairs, sans équivoque et objectivement mesurables. Aussi « le produit a été démontré comme fonctionnant à la satisfaction du client dans des conditions d’essai » n’est-il pas une bonne description de jalon!

Qu’entendons-nous « des conditions d’essai » ? Que devons-nous faire pour que le client soit « satisfait » ?

Soyez impliqués, prenez un rôle actif dans l’examen du contrat et assurez-vous que vous créez  seulement des jalons avec des livrables objectivement prouvables.

Cela vaut aussi la peine de penser aux contretemps. Qu’arrivera-t-il si le client ne réalise pas les tests ? Ou s’ils décident de l’utiliser en production bien qu’ils vous disent qu’il n’est pas « accepté » ? Efforcez-vous de vous assurer que l’on considère votre jalon comme « accepté » sauf si on vous le refuse dans un laps de temps limité après la livraison.

Qu’advient-il si ça tourne mal ?

Dans le troisième triangle, nous expliquons clairement les conséquences de l’échec. Ceci peut être lié à comment nous traiterons un taux d’erreur plus élevé que celui défini pour les tests d’acceptation. Ou bien comment une réclamation sous garantie sera traitée, ou les circonstances dans lesquelles le client aura le droit de rejeter les livrables. Ou encore, cela pourrait toucher à comment sont mesurés les niveaux de service et comment les pénalités seront calculées si vous manquez vos objectifs.

Si les choses tournent vraiment mal, il pourrait aborder comment votre organisation limite son exposition commerciale au cas où l’autre partie décide de vous poursuivre en justice, ou dans quelle mesure vous êtes protégés si vous recherchez une réparation légale à leur encontre.

La chose clé à comprendre d’une perspective de management de projet est ce que vous devez faire pour éviter des réclamations et des dommages et comment vous devriez aborder des problèmes s’ils se matérialisent pour les empêcher de devenir des litiges. Très peu de sociétés veulent aller au tribunal si elles peuvent l’éviter. En vous familiarisant avec comment votre contrat fonctionne, vous pouvez aider votre organisation à éviter une perte de temps, d’énergie et d’argent que tout litige cause inévitablement .

D’ « arme » à « manuel de l’utilisateur »

Comme vous pouvez le voir, le contrat n’est pas vraiment si différent du plan de projet. Son rôle devrait être de vous aider à livrer un projet réussi et vous supporter dans la décision sur les inévitables problèmes qui surgissent au long du projet. En adoptant le contrat comme « le manuel de l’utilisateur » pour vos relations commerciales, plutôt que juste une arme pour frapper l’adversaire, vous aiderez votre organisation à atteindre ses objectifs de projet et nouerez des relations plus fortes pour l’avenir.