Énoncé de travail. Aussi simple qu’il puisse paraître, en rédiger un correctement n’est pas une tâche facile. Mais rien n’est plus fondamental pour la réussite d’un projet. Si l’énoncé des travaux est trop vague, trop large ou trop générique, il peut laisser place à diverses interprétations, ce qui peut entraîner des problèmes en cours de route. C’est vrai pour un projet interne, et c’est doublement vrai lorsqu’il y a des vendeurs impliqués.
« L’incapacité à exécuter correctement un cahier des charges est souvent la raison pour laquelle les parties se retrouvent dans un conflit », déclare David M. Greenberg, avocat dans le groupe de pratique de la technologie, des médias et des télécommunications au bureau de New York de Greenberg Traurig LLP.
Pour réussir votre projet du premier coup, suivez ces directives pour rédiger un énoncé de travail efficace, ou SOW, comme on l’appelle affectueusement.
Comprenez ce qu’est un cahier des charges.
Un EDT définit l’étendue du travail requis et le délai dans lequel il doit être exécuté. C’est » la pierre angulaire d’un accord « , explique Nick Scafidi, responsable des achats informatiques chez le fournisseur d’énergie National Grid USA à Westboro, dans le Massachusetts. « Il définit les attentes, les produits livrables, ce qui est acceptable, le prix, le calendrier des prix. Sans cela, c’est comme dire à un entrepreneur : ‘Construisez-moi une maison’, en lui disant quand, quel type ou quelle taille. »
Savoir ce qu’il faut inclure.
Bruce Russell, qui a signé de nombreux SOW lorsqu’il était directeur de l’exploitation d’une société de développement de logiciels, affirme qu’un bon SOW comprend les éléments suivants :
- Les principaux produits livrables et la date à laquelle ils sont attendus.
- Les tâches qui soutiennent les produits livrables, ainsi que la partie — l’entreprise qui embauche ou le fournisseur de services — qui exécutera ces tâches.
- Le processus de gouvernance du projet, ainsi que la fréquence des réunions des comités directeurs.
- Les ressources nécessaires au projet, les installations qui seront utilisées et les équipements dont on aura besoin, ainsi que les exigences en matière de tests.
- Qui paiera quels coûts et quand.
« L’énoncé des travaux rassemble tous les éléments au début », dit Russell, maintenant professeur exécutif au College of Business de la Northeastern University à Boston. « Et plus vous pouvez le rendre précis, plus il est quantitatif, mieux c’est ».
Définissez le succès.
Un énoncé de travail devrait clarifier pour toutes les parties ce qui constitue un succès ou un échec, dit Melise R. Blakeslee, une avocate du groupe de la propriété intellectuelle, des médias et des transactions technologiques chez McDermott Will & Emery LLP à Washington.
« Vous devez décrire de manière adéquate ce qu’est le travail et les critères selon lesquels vous êtes tous deux d’accord » pour dire que quelque chose est terminé avec succès, dit Ruth Anne Guerrero, responsable des normes au Project Management Institute Inc. à Newtown Square, Pa. et ancienne chef de projet informatique.
Par exemple, dit-elle, si vous attendez de votre fournisseur qu’il élabore les besoins des utilisateurs, votre SOW devrait indiquer que le fournisseur doit interroger des groupes d’utilisateurs spécifiques et leur faire approuver les besoins avant que le travail ne soit considéré comme terminé. Cela définit mieux le succès que de dire simplement : » Le fournisseur produira les exigences des utilisateurs. »
La définition du succès dépend du projet, dit Guerrero. Les chefs de projet informatique doivent préciser si une mise en œuvre réussie est définie par la vitesse, le temps de réponse, la facilité d’utilisation ou les trois, puis les quantifier dans le SOW.
Ne pas oublier un calendrier.
Les mises en œuvre réussies ne peuvent pas être définies par la seule vitesse ou réactivité du système, cependant. Après tout, à quoi sert une excellente application s’il faut une décennie pour la construire ? C’est pourquoi un cahier des charges doit inclure des éléments temporels. Mme Guerrero recommande d’utiliser un langage qui permet une certaine flexibilité plutôt qu’une date fixe sur le calendrier. Un SOW devrait spécifier, par exemple, que les exigences de l’utilisateur final sont dues deux mois après la signature du contrat — une formulation qui fait encore avancer le projet tout en tenant compte des problèmes potentiels tels qu’un retard dans la signature du contrat.
Un SOW devrait également désigner des moments spécifiques pour les révisions formelles, afin que toutes les personnes impliquées puissent confirmer qu’elles sont sur la bonne voie, dit Matt Liberatore, professeur au département des technologies de décision et d’information et à la chaire John F. Connelly en gestion au College of Commerce and Finance de l’Université Villanova à Villanova, Pa.
Lier le paiement aux étapes importantes.
Un autre élément clé pour garder le travail sur la bonne voie est de fixer des jalons spécifiques dans le SOW et de lier le paiement à l’achèvement réussi, dit Blakeslee.
Lorsque Scafidi rédige un SOW, il précise que les paiements aux fournisseurs sont effectués à l’acceptation des livrables clés. Il note également qu’il conservera une partie de la rémunération jusqu’à ce que le fournisseur prouve que tous les livrables fonctionnent ensemble.
Utilisez un langage que tout le monde peut comprendre.
Le département informatique et ses fournisseurs ne sont pas les seuls à utiliser le SOW, dit Blakeslee. Ne le rédigez donc pas comme si seul le personnel informatique allait le voir. « Il doit être compréhensible pour les utilisateurs finaux, les fournisseurs de services, la direction et pour un juge », dit-elle.
Soyez précis.
Bien que de nombreuses parties doivent comprendre l’énoncé des travaux, soyez précis dans la description de la portée et des exigences du projet, dit Blakeslee. Elle a vu des documents qui fixaient des objectifs vagues, tels que « travailleront au mieux de leurs capacités ». Elle compare cela à un propriétaire qui engage un peintre avec des instructions pour « utiliser le meilleur effort possible ».
« Si le peintre fait cela mais peint votre maison en violet au lieu de blanc, alors vous n’auriez pas de réclamation contre lui », dit-elle.
Scafidi a pris ces conseils à cœur. Au lieu de dire qu’une tâche prendra « un temps raisonnable », Scafidi écrit : « La tâche spécifiée ne prendra pas plus de quatre heures. »
« Les avocats se sentent bien quand nous avons une définition claire et sans ambiguïté sur des choses comme ça », dit-il.
Souvenir des besoins en matière de postproduction.
Guerrero recommande d’inclure les exigences de postproduction dans le SOW. Expliquez clairement les tests et le soutien dont vous aurez besoin de la part du fournisseur, dit-elle. Et si vous prévoyez de confier le support du système à des personnes internes après l’installation, le cahier des charges doit préciser si le fournisseur formera votre personnel. Un tel libellé, dit-elle, garantit que le fournisseur ne « livre pas simplement le système et s’en va ».
Pratt est un rédacteur collaborateur de Computerworld à Waltham, Mass. Contactez-la à [email protected].