Quand le contract management oublie le project management
Lorsque j’ai reçu la newsletter de l’IACCM, j’ai été intrigué par un article en particulier:
Cet article m’a interpelé d’abord parce qu’il parle de contract management, de check-list (dont je suis un grand fan – voir ici) et de CMP, que ce sujet a été traité dans un article précédent, et qu’il m’a amené à réfléchir là-dessus…
Des exemples
D’abord, j’adore les exemples, qui sont issus du terrain. C’est toujours bien d’avoir des exemples vécus. A la fin de l’article, je me suis dit qu’il avait raison l’auteur, que le CMP ne peut pas être une simple check-list, qu’il faut faire attention aux non-dits et sous-entendus…
Wait a minute !
Euh, revenons un peu en arrière… Le premier exemple, c’est un fournisseur qui ne peut pas avoir accès au site parce qu’il y a des travaux de maintenance sur la route d’accès – route sous la responsabilité du client.
Soyons un peu pragmatiques quelques instants: quand tu es client, que tu attends du matériel, que la route d’accès est impraticable, ne préviens-tu pas le fournisseur ?
Et quand tu es fournisseur, qu’il n’y a qu’une route d’accès, ne vérifies-tu pas avec le client que tu pourras livrer ? Surtout si tu n’as que cette livraison à faire ? Et si tu as plusieurs livraisons, que tu travailles beaucoup sur ce chantier, comment se fait-il que tu ne connaisses pas l’état de la route d’accès ???
L’opérationnel d’abord
Cette première dispute n’aurait pas du éclater, sauf à vouloir qu’elle arrive soit du fait du client qui fait exprès d’empêcher l’accès, soit du fait du fournisseur qui se pointe pour faire valoir une extension de délais et/ou une rallonge financière.
Dit autrement: cette dispute est plus liée à une défaillance de la gestion de projet qu’à une mauvaise écriture du contrat. Les chefs de projets et différents intervenants auraient du anticiper cette difficulté. Encore une fois, quand il n’y a qu’une route d’accès, on fait attention !
Le Quality Assurance Plan
Et que dire du second exemple ? Un cas où les certificats n’étaient pas fournis lors de la livraison… C’est pour cela qu’il est urgent de démarrer un projet avec les exigences du client en termes de validations, tests, essais. Encore une fois, c’est une bonne pratique de gestion de projet, appelée parfois Quality Assurance Plan, ou Inspection Test Plan. Ce document décrit les critères qui font que le client va accepter ou rejeter les travaux.
Alors oui, le contrat aurait pu être mieux écrit, mais d’autres difficultés auraient été rencontrées. Il est impossible d’avoir un contrat parfait.
Il est impossible d’avoir un contrat parfait
Pour moi, cet article est assez symptomatique de ce que j’observe bien souvent: on pense que le contrat doit régler tous les problèmes en avance, alors qu’il n’est que le début (imparfait) d’une relation (imparfaite) qu’il faut faire avancer. Et c’est à cela que sert la gestion de projet. Je ne dis pas que le contract management et les contrats ne servent à rien (bien au contraire), mais qu’ils ne sont ni les maux ni les remèdes à tout et qu’ils doivent grandir avec les autres disciplines.
Et vous, quelles sont les difficultés que vous avez rencontrées et qui auraient pu être évitées par une meilleure gestion de projet ?
-
Jean-Charles Savornin
Comments (5)
Laisser un commentaire
du contract management
Tres belle reflection. Même si le mot nest pas écrit on voit toute l’importance d’organiser de bons kick off meetings.
Et vous, quelles sont les difficultés que vous avez rencontrées et qui auraient pu être évitées par une meilleure gestion de projet ? =>
Je répondrais, en référence à mes expériences récentes : la capacité à mobiliser les bonnes ressources au bon moment, le fait d’avoir les bons acteurs, contributeurs, experts, sponsor, dispos quand cela est nécessaire pour le projet.
C’est à dire le fait de constituer la bonne équipe projet et de l’animer. C’est la toute « base » du management de projet, mais elle n’est pas toujours au RDV malheureusement !
Et oui Adeline, la base: les projets sont faits par des personnes, une équipe. Sans équipe, pas de projet !
La perte de connaissance. Il arrive parfois que l histoire d un projet se perde : un chef de projet qui demissionne, des discussions d appel d offres non tracées, un projet qui dure des années et qui a connu beaucoup (trop) d interlocuteurs… La perte d historique peut avoir des conséquences terribles. Il faut savoir s en prémunir :tracer les informations par des CRR, réaliser un recouvrement équipe offre / projet, sauvegarder les données importantes sur un fichier partagé…
Oui, la traçabilité, un élément clé des projets, et les transferts entre personnes sont cruciaux pour échanger sur l’implicite. La perte d’info existe néanmoins, la question est comment la maîtriser.