Gestion de projet – Vers les méthodes agiles
240
certaine proportion, l’un des paramètres, client et prestataire conviennent de constituer
un comité des changements et de définir un processus de gestion des changements. L’effet
boomerang, malheureusement, c’est l’avenant du prestataire présenté systématiquement
au client.
Comment rendre le contrat au forfait compatible avec une démarche agile ?
La réponse de l’expert Claude Aubry, consultant indépendant dans la mise en place des
méthodes agiles.
La contractualisation des relations entre le client et l’équipe de réalisation n’est pas obligatoire, ni
même recommandée par les méthodes agiles : le Manifeste agile rappelle qu’une bonne collaboration est plus importante qu’un contrat. Cependant, les directions juridiques et financières, en
rationalisant les achats de prestations, imposent bien souvent un contrat à prix fixé aux fournisseurs. De leur point de vue, il est impératif d’avoir une enveloppe budgétaire définie à l’avance.
Comment un client, qui est déjà convaincu des bienfaits de l’agilité, peut-il élaborer un appel
d’offres et sélectionner un fournisseur pour un contrat au forfait dans ce contexte ?
À ce client prêt à effectuer la transition vers l’agilité, je conseille d’élaborer un appel d’offres
agile (AOA), dans lequel c’est un processus de développement agile qui est préconisé aux
fournisseurs (par exemple Scrum, qui est le plus simple à mettre en œuvre). Le budget et le
délai, au lieu d’être demandés aux fournisseurs, sont fixés par le client et annoncés dans
l’AOA. Comme il est impossible de définir le périmètre fonctionnel à l’avance, le client fournit
simplement sa vision du projet dans l’AOA. Le périmètre deviendra la variable d’ajustement.
Le fournisseur effectue sa sélection sur la qualité de la réponse, la pertinence du processus
(agile) proposé et sur les compétences de l’équipe pressentie. Par rapport à la pratique d’évaluation actuelle des réponses à appel d’offres, ce qui change, c’est que le prix n’est pas considéré,
puisque c’est le client qui le fixe.
Le contrat avec le fournisseur est toujours un contrat au forfait, avec prix et date fixés. Mais
c’est un contrat au forfait agile (CFA) qui se différencie du contrat classique parce qu’il impose
une livraison à la fin de chaque itération et parce que le périmètre fonctionnel, défini initialement dans la vision, est ajustable. Avec un CFA, l’objectif du client n’est plus de reporter les
risques sur le fournisseur, il collabore avec lui pour obtenir le meilleur produit dans le délai
défini.
Les clauses du contrat sont adaptées à l’agilité. Voici quelques exemples de ce qu’il est possible d’y introduire, pour le bénéfice du client :
– Le client doit recevoir un produit partiel, mais fonctionnel, à la fin de chaque itération : il peut
ainsi fournir un feedback rapide.
– Le client peut arrêter le contrat à la fin de chaque itération (en contrepartie d’une indemnité,
calculée en fonction du temps passé pour le fournisseur) : il peut ainsi stopper à temps un
projet voué à l’échec.
– Le client définit les priorités : le fait de développer les fonctionnalités à forte valeur ajoutée en
premier permet de lever tôt les risques (risques techniques, bien sûr, mais surtout risques de
livrer un produit en inadéquation avec les attentes).
– Le client peut changer d’avis sur le contenu fonctionnel (sur les parties qui n’ont pas encore
commencé), à condition que ce qu’il ajoute au périmètre soit contrebalancé par ce qu’il y retire.
GestProjInform Livre Page 240 Vendredi, 3. avril 2009 12:07 12
240
certaine proportion, l’un des paramètres, client et prestataire conviennent de constituer
un comité des changements et de définir un processus de gestion des changements. L’effet
boomerang, malheureusement, c’est l’avenant du prestataire présenté systématiquement
au client.
Comment rendre le contrat au forfait compatible avec une démarche agile ?
La réponse de l’expert Claude Aubry, consultant indépendant dans la mise en place des
méthodes agiles.
La contractualisation des relations entre le client et l’équipe de réalisation n’est pas obligatoire, ni
même recommandée par les méthodes agiles : le Manifeste agile rappelle qu’une bonne collaboration est plus importante qu’un contrat. Cependant, les directions juridiques et financières, en
rationalisant les achats de prestations, imposent bien souvent un contrat à prix fixé aux fournisseurs. De leur point de vue, il est impératif d’avoir une enveloppe budgétaire définie à l’avance.
Comment un client, qui est déjà convaincu des bienfaits de l’agilité, peut-il élaborer un appel
d’offres et sélectionner un fournisseur pour un contrat au forfait dans ce contexte ?
À ce client prêt à effectuer la transition vers l’agilité, je conseille d’élaborer un appel d’offres
agile (AOA), dans lequel c’est un processus de développement agile qui est préconisé aux
fournisseurs (par exemple Scrum, qui est le plus simple à mettre en œuvre). Le budget et le
délai, au lieu d’être demandés aux fournisseurs, sont fixés par le client et annoncés dans
l’AOA. Comme il est impossible de définir le périmètre fonctionnel à l’avance, le client fournit
simplement sa vision du projet dans l’AOA. Le périmètre deviendra la variable d’ajustement.
Le fournisseur effectue sa sélection sur la qualité de la réponse, la pertinence du processus
(agile) proposé et sur les compétences de l’équipe pressentie. Par rapport à la pratique d’évaluation actuelle des réponses à appel d’offres, ce qui change, c’est que le prix n’est pas considéré,
puisque c’est le client qui le fixe.
Le contrat avec le fournisseur est toujours un contrat au forfait, avec prix et date fixés. Mais
c’est un contrat au forfait agile (CFA) qui se différencie du contrat classique parce qu’il impose
une livraison à la fin de chaque itération et parce que le périmètre fonctionnel, défini initialement dans la vision, est ajustable. Avec un CFA, l’objectif du client n’est plus de reporter les
risques sur le fournisseur, il collabore avec lui pour obtenir le meilleur produit dans le délai
défini.
Les clauses du contrat sont adaptées à l’agilité. Voici quelques exemples de ce qu’il est possible d’y introduire, pour le bénéfice du client :
– Le client doit recevoir un produit partiel, mais fonctionnel, à la fin de chaque itération : il peut
ainsi fournir un feedback rapide.
– Le client peut arrêter le contrat à la fin de chaque itération (en contrepartie d’une indemnité,
calculée en fonction du temps passé pour le fournisseur) : il peut ainsi stopper à temps un
projet voué à l’échec.
– Le client définit les priorités : le fait de développer les fonctionnalités à forte valeur ajoutée en
premier permet de lever tôt les risques (risques techniques, bien sûr, mais surtout risques de
livrer un produit en inadéquation avec les attentes).
– Le client peut changer d’avis sur le contenu fonctionnel (sur les parties qui n’ont pas encore
commencé), à condition que ce qu’il ajoute au périmètre soit contrebalancé par ce qu’il y retire.
GestProjInform Livre Page 240 Vendredi, 3. avril 2009 12:07 12