Styles

jeudi 13 août 2009

Dates cibles et échéances : compromis comme promis

Tout le monde a, un jour, travaillé sur un projet si mal défini ou si maladroitement suivi qu'on a plus qu'une seule envie : quitter le radeau avant qu'il ne coule. Vu la proportion gigantesque de projets ne respectant ni ses délais, ni son périmètre initial ou ses coûts (source), il est très probable que vous ayez déjà participé à ce genre de fiasco.

Dans les projets à la dérive, les échéances (deadlines) sont souvent dépassées, faisant éclater des disputes sans fin dans le but de trouver des coupables, mais surtout pas d'essayer de remettre de l'ordre pour la suite du projet.

Quand ces horribles projets finissent par mourir définitivement (et ça peut prendre beaucoup de temps !), il est toujours intéressant de se pencher dessus à froid, pour essayer de comprendre ce qui n'a pas marché. Ce travail de reflexion à posteriori (les anglosaxons aiment bien utiliser le terme « project post-mortem ») est malheureusement trop rarement effectué, ou seulement de façon incomplète.

Sur plusieurs de ces projets, on s'aperçoit que les échéances ont été définies avant même d'estimer quoique ce soit sur le projet. De plus, ces dates n'ont jamais été remises en causes pendant toute la durée du projet. Est-ce que ce sont réellement des échéances (deadlines) ou seulement des dates cibles (« target dates ») ? Une date cible est bien différente d'une échéance. C'est ce que décrit clairement Conrad Weisert dans son article « Les échéances et dates cibles des projets : 5 conseils pour éviter le désastre » :
La plupart des « échéances » (deadlines) ne sont en fait que des dates cibles. La différence réside dans ce qui survient si la date n'est pas respectée :
  • quand une échéance est ratée, il ne reste plus aucun intérêt à compléter l'engagement. Par exemple :
    • s'inscrire à une compétition
    • publier le catalogue de Noël prochain
  • Quand une date cible est ratée, les conséquences peuvent être aussi désastreuses que pour une échéance, mais vous avez toujours à finir le travail. Si « date cible » semble trop vague pour vous, alors remplacez cette expression par « date de fin » ou « date de livraison ».
Encore faut-il gérer correctement la planification d'un projet de développement pour pouvoir définir des dates cibles ou des échéances. Cela nécessite de maîtriser un tant soit peu l'art délicat de l'estimation et d'être en mesure d'offrir des preuves de celle-ci.

Sur son site, Conrad revient sur ces notions importantes, en relation avec la gestion de projet et le développement logiciel. L'estimation n'est pas qu'une affaire d'expérience. C'est aussi et surtout le moyen de montrer par « a + b » qu'un projet tiens la route et saura tenir ses délais. Or seul celui qui dit que quelque chose peut être fait doit en apporter la preuve. Un client ou une division Marketing d'une entreprise se doit d'être ambitieux quant à la définition du produit et à ses dates de livraison ou de mise sur le marché. Or ce n'est ni le client ni cette division marketing qui vont prouver qu'on est capable de réaliser ses rêves. C'est au chef de projet (ou au chargé d'affaire dans le cas de sous-traitances de développement) de trouver des solutions qui puissent répondre au mieux aux exigences et contraintes exposées.

La définition de plan permet d'éclaircir le projet et de notamment exprimer de nouvelles exigences et contraintes liées aux solutions. Ce n'est qu'en face des éléments issues de toutes les parties que l'investisseur (le client, la division marketing...) lance le projet.

Dans le cadre de la sous-traitance de production (pour le développement logiciel au forfait par exemple), il est facile pour un chef de projet de se faire imposer des dates cibles du simple fait:
  • de la relation contractuelle qui existe entre le client et son cahier de charge d'un côté, et le fournisseur et sa volonté de gagner le contrat de l'autre (souvant « à tout prix »).
  • de la rédaction de la réponse à l'appel d'offre par une personne (un « chargé d'affaire ») autre que celui qui va mener le projet jusqu'à son terme.
Même dans le cas de sous-traitance, il est souhaitable que la réponse à l'appel d'offre soit ambitieuse et rédigée par une personne autre que le chef de projet, car ce dernier a naturellement tendance à voir énormément de risques et à avoir une attitude extrêmement prudente, encore plus s'il n'est pas « intéressé » personnellement (oui, oui, par cette basse chose qu'on appelle « l'argent ») au projet. Mais c'est au final, au chef de projet de ramener tout le monde à la réalité.

Aucun commentaire: