Cet excellent ouvrage sur les méthodes agiles de gestion de projet ... que l'on peut associer au développement des logiciels, mais qui ont leur application dans tout projet propose un angle de vue différent. C'est une approche des processus en environnement instable, environnement aujourd'hui dominant.

Du coup on change de point de vue ... la contrainte principale d'hier qui était la satisfaction d'un besoin complet et exhaustif du client, est concurrencée par l'incertitude de l'environnement. Le délai est primordial, le coût est toujours mis en avant. Il faut répondre à un besoin mouvant avec un produit d'un niveau de qualité le plus élevé possible dans un délai et un budget fixe.

Certains choisiront surement de "verrouiller" le besoin, même mouvant pour planifier correctement le projet et assurer le délai dans l'enveloppe budgétaire : "Le client a validé les spécifications, il ne peut plus changer d'avis ... mais on peut faire un avenant au contrat ...". Conséquence, soit on accepte les modifications est on passe un temps fou dans le cahier des charges, soit on livre des fonctionnalités non utilisé et le délai n'est pas respecté. D'autres ajusteront la réalisation par des livraisons intermédiaires fréquentes en commençant sur les fonctionnalités qui ont la plus grande valeur pour le client, quitte ensuite à négocier dans un périmètre fonctionnel à valeur constante des éléments secondaires afin d'ajuster le besoin au fur et à mesure des itérations de réalisation.

Seulement voilà, l'approche adaptive, agile, propose l'incertitude du niveau de qualité d'entrée de jeu et dit clairement : "Nous ne savons pas dans le détail ce qui va être réalisé, nous assurons d'apporter la valeur au début, mais pour le reste on verra plus tard ...". L'approche planifiée est bien plus rassurante, car elle se propose d'être exhaustive, détaillée, complète, validée ... Mais qui a déjà vu un cahier des charges complet ? Qui a déjà vu un client concerné par le projet ne jamais changer d'avis ?