Où s'arrête la « gestion du changement » et où commence « l'échec du projet » ?

Question

Je suis entré dans un mini-argument avec mon patron récemment concernant «l'échec du projet». Après trois ans, notre projet de migration d'une base de code vers une nouvelle plate-forme (un projet sur lequel je me trouvais pendant 1,5 ans, mais mon chef d'équipe n'a fait que quelques mois).Lui, ainsi que la haute direction de mon entreprise et du client (je fais partie de ces horribles consultants dont vous entendez tant parler.Mon engagement est une "Application Outsourcing") qui a déclaré le projet réussi.Je n’étais pas d’accord, affirmant que d’anciennes présentations que j’avais trouvées montraient que par rapport au calendrier initial, le retard de déploiement se mesurait mieux en mois et pouvait potentiellement être mesuré en années.J'ai expliqué ce que je sais de l'échec des projets, ainsi que les études et statistiques derrière les taux d'échec.Il a répondu que tout cela était du domaine universitaire et qu'aucun projet qu'il dirigeait n'avait échoué, grâce aux merveilles de la gestion du changement et des risques - ce qui semble se résumer à expliquer les retards et à réévaluer le calendrier en fonction de nouvelles données.

Peut-être qu'un tel conseil diffère des autres projets, mais il semble qu'il ne s'agisse que d'un échec enveloppé dans un nom plus joli pour éviter le stigmate de ne pas avoir réussi à livrer à temps, dans les limites du budget ou avec toutes les fonctionnalités.Le fait qu'il ait expliqué que mon entreprise offrait gratuitement des heures de travail afin de terminer le projet dans les limites du budget maximum en dit long.

Alors je vous demande ceci :

• Qu’est-ce que la gestion du changement et comment s’applique-t-elle à un projet ?
• Où s'arrête la « gestion du changement » et où commence « l'échec du projet » ?

---

@shog9 :
Je ne parlais pas d'un jeu de reproches avec les consultants, d'autant plus que dans ce cas, je représenter les consultants.Je cherchais des avis sur le moment où un projet devrait être considéré comme « échoué », indépendamment du fait que la fonctionnalité nécessaire était finalement mis en œuvre.
Je cherche la différence entre "c'est en fait un peu plus complexe que nous le pensions, et ça va prendre encore une semaine", ce qui, je m'attendrais, est quelque peu typique, et "l'échec du projet" - quelle que soit la manière dont vous voulez définir l'échec.Y a-t-il même une différence ?Ce niveau mineur de retard dans le calendrier constitue-t-il un « échec du projet » statistique ?

Answer 1

Je pense que la plupart du temps, nous, les développeurs, oublions que ce que nous faisons tous est, après tout, une question de business.

De ce point de vue, un projet n’est pas un échec tant que le client est prêt à payer pour cela.Tout dépend du client, certains clients sont plus patients et comprennent mieux les risques liés au développement de logiciels, d'autres ne paieront tout simplement pas en cas de retard important.

Quoi qu'il en soit, à propos de votre question.Chaque fois que vous faites évoluer un projet, il y a des risques. Peut-être que vous planifiez la fin du projet à une certaine date, mais cela prendra environ six mois de plus que prévu.Dans ce cas, vous devez équilibrer ce que vous avez déjà dépensé et ce que vous avez à gagner par rapport aux risques que vous prenez.Il existe en fait toute une science appelée « prise de décision » qui l'étudie au niveau logiciel, donc votre patron n'a pas tort du tout.

Examinons quelques questions : le client est-il prêt à attendre le projet ?Est-il prêt à assumer certains surcoûts ?Même s'il ne le fait pas, vaut-il la peine de terminer le projet en assumant les coûts supplémentaires au lieu de jeter tout le travail déjà effectué ?L’entreprise peut-elle assumer ce qui est déjà perdu ?

La vraie réponse à votre problème se cache derrière ces questions.Vous ne pouvez pas affirmer un point et dire ici que si le projet n'est pas terminé à ce moment-là, c'est un échec.Quant à votre situation particulière, qui sait ?Votre patron a probablement plus d'informations que vous, donc votre travail consiste à lui dire comment se déroule le projet, combien cela prendra et combien cela coûtera (en termes d'heures/homme si vous le souhaitez)

Answer 2

À moins que les objectifs ne soient clairement indiqués au début du projet, il n'y a pas de lignes claires entre le «succès» et «l'échec». Souvent, un projet aurait un degré variable de succès / échec.

Pour certains, le simple fait d'intégrer certains concepts dans le code serait un succès, tandis que d'autres peuvent mesurer le succès comme la récupération de tous les investissements et la réalisation de bénéfices.Deux modes d'échec bien connus sont les retards dans les délais et la détérioration de la qualité, mais dans le monde réel, les gens ne semblent pas s'en soucier beaucoup.

Des moyens simples de contourner le calendrier sont de laisser les gestionnaires faire des demandes quand ils le souhaitent (les fonctionnalités glissent) et de laisser les programmeurs coder ce qu'ils estiment être juste (codage cowboy).Processus de gestion du changement tel que planification des sprints de mêlée et jeu de planification de XP en sont quelques exemples.Ces thèses sont quelques-unes des tentatives de la direction et des développeurs pour expédier des produits fiables à temps.Si l’une ou l’autre des parties n’est pas intéressée par la fiabilité ou la ponctualité, la gestion du changement ne serait alors pas utile.

Answer 3

Je suppose que la réussite du projet dépend de l'identité du client.Si les clients étaient les dirigeants de l’entreprise et qu’ils étaient satisfaits, alors le projet a réussi, quels que soient les échecs survenus en cours de route.

Answer 4

Andy Rutledge a écrit un article assez intéressant sur le succès.Même si le titre est Discussions préalables à l'offre, l'article définit avoir un projet réussi, ce qui pour Andy implique :

1. Est-ce que moi ou mon équipe serons autorisés à apporter notre meilleur travail au résultat final ?
2. Le client est-il prêt à s’engager dans le projet de manière appropriée ?
3. Le client est-il prêt à démarrer ce projet ?
4. Le client est-il prêt à investir sa confiance dans mes idées ou celles de mon équipe ?
5. Suis-je ou mon équipe est-elle prête à remplir ou à dépasser les exigences du projet ?

Cet article a été souligné par Obie Fernandez, un consultant à succès, dans son Faire l'agitation conférence sur le conseil.

Answer 5

Qu’est-ce que la gestion du changement et comment s’applique-t-elle à un projet ?

La gestion du changement consiste à approuver et à communiquer les modifications apportées à un projet avant qu'elles ne se produisent.Si quelqu'un sur votre projet (utilisateur, sponsor, membre de l'équipe..quiconque) souhaite ajouter une fonctionnalité, le changement doit être documenté et analysé pour l'effet.Toute modification résultante de la portée, du budget et du calendrier doit ensuite être approuvée avant que le changement ne soit entrepris.Ces changements sont généralement approuvés par votre sponsor, votre comité directeur ou votre client.

Une fois les modifications approuvées et acceptées, vous obtenez votre nouveau plan.Peu importe le budget ou le calendrier initial.

La gestion du changement sur les projets repose sur le principe du « pas de surprise ».Les bonnes personnes (votre comité de contrôle des modifications) doivent approuver toute modification apportée à la portée, au calendrier et au budget avant de pouvoir y donner suite.

Une chose à retenir est qu’il peut y avoir certaines contraintes et tolérances explicites ou implicites au changement.Vous devrez peut-être livrer votre projet avant une certaine date pour répondre aux exigences réglementaires gouvernementales.Ou bien, votre organisation peut avoir un seuil selon lequel, dès qu'un budget de projet dépasse de 30 % le budget initial, il doit passer au niveau « C », sinon le projet est tué.Étudier et énoncer explicitement ces seuils et tolérances dès le départ est un bon moyen de mener à bien des projets plus réussis.

Où s'arrête la « gestion du changement » et où commence « l'échec du projet » ?

Si un projet respecte la portée, le calendrier et le budget approuvés, il est réussi.

Cependant, cela peut encore être considéré comme un échec.Les revues post-implémentation sont un bon outil pour qualifier cela avec vos parties prenantes (pas seulement votre patron).Il serait également intéressant d'examiner la réalisation des avantages pour voir en dehors de la boîte noire du projet et son impact sur l'entreprise dans son ensemble.