• 19avr


    Le Diable est dans les détails … des définitions de succès

    Certes, le rapport du Standish Group a depuis longtemps mis l’accent sur des vérités qu’il ne fait pas bon ignorer, entre autres l’importance des utilisateurs, du sponsoring de la DG, le fait que toutes les fonctionnalités fournies ne sont pas utilisées, qu’il pourrait même y avoir une règle des 80-20 (20% des fonctions, 80% des usages), etc. Ses détracteurs diront toutefois que les mesures et les méthodes sont insuffisamment décrites, interrogeront la fiabilité de la base utilisée en tant qu’échantillon représentatif (ce sans même parler d’une approche statistique rigoureuse qui ne semble pas être mise en pratique, car si ce ne sont que des grands comptes avec des grands projets, il est logique que les chiffres varient peu d’une année sur l’autre … ), voire interrogeront l’art et la manière de poser des questions (la question « parlez-nous de vos échecs » n’incite pas à parler naturellement des succès).
    Quelle que puisse être la fiabilité du rapport au sens de la déontologie du Standish Group, de l’honnêteté des personnes interrogées ou de l’importance et la représentativité de la base, cette controverse met en lumière plusieurs points sur la gestion de projet qui méritent débat et approfondissement.
    En premier lieu, rappelons les définitions initiales du Standish Group pour catégoriser les projets:

    • Résolution type 1, ou projet de type « succès » : Le projet a été complété en temps et heure, dans le respect du budget et a livré tous les services et fonctionnalités initialement spécifiés.
    • Résolution type 2, ou projet de type « challengé » : le projet a été complété, est opérationnel mais a dépassé les estimations de budget et de temps et a livré moins de services et de fonctionnalités qu’initialement spécifié.
    • Résolution type 3, ou projet de type « déficient » : le projet a été annulé à un moment du cycle de développement.

    Que penser de cette définition du « succès » ? Force est de constater que le Standish Group définit le succès d’un projet sur la base du respect des estimations initiales de coût, délais, fonctionnalités. Maintenant, est-ce que livrer 100% des fonctionnalités prévues initialement dans un cahier des charges est un critère de succès ? Pas forcément … cela va même à l’encontre des logiques de priorisation et d’analyse de la valeur, ainsi que des pratiques des méthodes agiles.
    Le « succès » d’un projet pour l’entreprise ne se mesure pas à la fiabilité des estimations coûts, délais, fonctionnalités initiales, pas plus que le succès de son pilote à les avoir respectées
    Il se peut très bien que dans le cours d’un projet, des fonctionnalités a priori indispensables dans l’esprit des utilisateurs apparaissent inutiles à automatiser, car trop complexes pour peu de valeur ajoutée, alors que la fourniture de données pour une activité manuelle suffirait à couvrir le besoin. Sans parler des variations de l’environnement qui peuvent conduire à des demandes de changement. Dans un projet complexe et long, les estimations coûts, délais et fonctionnalités varient naturellement au cours du temps et se précisent par itération.

    Rien n’est immuable et il est également très rare de disposer de spécifications si claires et sans ambiguïté au démarrage d’un projet qu’elles ne nécessitent pas d’être amendées par la suite.

    Page 2/6 – Suite de l’article – 4 pages

    Article entier :« Page précédente Page suivante »

Laisser un commentaire

Avertissement: Les commentaires sont soumis au modérateur ce qui peut retarder leur publication. Il n'est pas utile de les renvoyer dans l'intervalle, merci.