20 causes d’échecs d’un projet

Trouvé sur le site www.chef-de-projet.org, suite à une présentation faite par l’Espace Numérique de l’Isère hier soir, sur le thème « Réussir son projet informatique : comment avoir les bons réflexes et éviter de se tromper ? ».

Sans remettre en cause le bien fondé ou pas des informations présentent sur le site, j’essaye d’étudier dans cet article, comment l’agilité permet, ou pas, d’éviter ces 20 problèmes.

Au bilan : 17 RESOLUS et 3 OUVERTS .. et VIVA AGILISTA !!!

Pour plus de détails …

Axe 1 Organisation du projet

• Piège 1 Le problème est mal défini et mal délimité –> RESOLU. Incrément de produit et feedback régulier garantissent la fourniture du produit attendu par le client
• Piège 2 Les exécutifs refusent de voir la réalité –> OUVERT. Même problème en agile si les décideurs n’adhèrent pas
• Piège 3 Les plannings sont réalisés à la petite semaine, sans impliquer les acteurs de terrain –> RESOLU. Toute l’équipe participe et les utilisateurs finals sont impliqués
• Piège 4 Les plannings sont trop rigides et imposent des coupes franches improvisées –> RESOLU. Le périmètre est variable avec un timeboxing strict des itérations.
• Piège 5 Les estimations à la bonne franquette deviennent les objectifs à tenir –> RESOLU. Les estimations en « Story Points » évitent la pression sur les charges
• Piège 6 Les budgets sont trop verrouillés –> RESOLU. La notion de « business value » permet de faire les bons choix en terme de budget et de coût de réalisation.donne une réelle solut… mais s’il n’y a même pas le budget pour la release 1 … rien à faire !
• Piège 7 Le projet n’est pas en phase avec les budgets alloués –> RESOLU. L’approche itérative et incrémentale permet de livrer une version du produit dans le budget et de plus je suis convaincu que que l’agilité permet de réduire les coûts

Axe 2 Coopération étendue, team building

• Piège 8 Les responsabilités sont trop mal définies ou changent constamment –> RESOLU. La réduction du nombre de rôles simplifie grandement le problème. Pour ce qui est du changement constant … les agilistes adorent cela 🙂
• Piège 9 Les équipes ne sont qu’un ensemble d’individualités –> RESOLU. La communication et l’interaction des personnes est une valeur de l’agilité mise en oeuvre avec toutes les méthodes.
• Piège 10 Les acteurs du projet sont déplacés et réaffectés à tort et à travers –> OUVERT. C’est un problème de management et non de gestion de projet.
• Piège 11 Un manque de participation des autres parties prenantes –> RESOLU. Les démos impliquent fortement toutes les parties prenantes de façon très régulière (toute les 2 à 4 semaines)
• Piège 12 L’absence de véritable communication entre les exécutants et les managers du projet –> RESOLU. Il n’y a plus de « Managers du projet » et le « Product Owner » est totalement intégré dans l’équipe de réalisation.

Axe 3 Assisance à l’anticipation

• Piège 13 Les enjeux mal précisés évoluent et bouleversent les priorités –> RESOLU. La gestion des priorités est un des points forts des méthodes agiles
• Piège 14 Les ressources sont inappropriées ou mal utilisées –> RESOLU. L’approche agile consiste à délivrer de la « business value » et non d’occuper les ressources comme dans les méthodes traditionnelles.
• Piège 15 Les exécutants ont perdu de vue les objectifs initiaux –> RESOLU. Les objectifs sont redéfinis régulièrement et partagés avec toute l’équipe
• Piège 16 L’instrument de mesure est inadéquat…–> RESOLU. Le suivi par la mesure des délais et des coûts n’est pas pratiqué en agile, d’autres indicateurs sont utilisés
• Piège 17 Le balisage du projet ne permet pas une appréciation concrète de l’avancement… –> RESOLU. L’avancement agile est basé sur une réalité (nombre de points produits) et non des estimations en % d’avancement

Axe 4 Intégration

• Piège 18 Les aspects techniques du projet sont privilégiés aux dépens des besoins fonctionnels –> RESOLU. Tous les besoins sont listés dans un seul et unique document, et sont priorisés par une seule personne.
• Piège 19 Le chef de projet cherche à reproduire ce qu’il fait habituellement aux dépens des besoins propres de l’entreprise –> RESOLU. Le chef de projet traditionnel n’existe plus, l’équipe est autonome et en amélioration constante grâce aux rétrospectives régulières.
• Piège 20 Le budget initial ne tient pas suffisamment compte des besoins propres de l’intégration –>OUVERT. La partie déploiement et formation de tous les utilisateurs n’est pas réellement adressé par les méthodes agiles (manque parfois de vision système comme dans le Lean)