Où finit la "Gestion des modifications" et "Échec du projet"?

Question

J'ai récemment eu un mini-argument avec mon patron concernant "l'échec du projet". Après trois ans, notre projet de migrer une base de code vers une nouvelle plate-forme (un projet sur lequel je travaillais depuis un an et demi, mais sur lequel mon équipe dirigeait depuis quelques mois seulement) a été lancé. Lui, ainsi que les cadres supérieurs de mon entreprise et du client (je suis un de ces consultants terribles dont on entend tellement parler, mon engagement est «Outsourcing d'application») ont déclaré que le projet était un succès. Je n'étais pas d'accord, affirmant que les anciennes présentations que j'avais trouvées montraient que, par rapport au calendrier initial, le retard dans le déploiement était mieux mesuré en mois et pouvait potentiellement être mesuré en années. J'ai expliqué ce que je sais de l'échec du projet, et les études et les statistiques derrière les taux d'échec. Il a répondu que c'était tout le monde universitaire, et qu'aucun projet qu'il dirigeait n'avait échoué, grâce aux merveilles du changement/gestion des risques - ce qui semble expliquer les retards et réévaluer le calendrier en fonction des nouvelles données. Peut-être que cette consultation diffère des autres projets, mais il semble que ce soit juste un échec enveloppé dans un nom plus joli pour éviter le stigmate d'avoir échoué à livrer à temps, sur le budget, ou avec toutes les fonctionnalités. Le fait qu'il m'ait expliqué que mon entreprise donnait gratuitement des heures de travail pour terminer le projet dans le budget maximal en disait long.

Je vous demande ceci:

• Quelle est la gestion du changement, et comment il applique à un projet?
• Où se termine la "gestion des modifications" et où "échec du projet" commence?

---

@ Shog9:
Je ne demandais pas d'un jeu de blâme avec les consultants, d'autant plus que dans ce cas, je représente les consultants. Je cherchais des vues sur quand 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 "ceci est en fait un peu plus complexe qu'on ne le pensait, et ça va être une autre semaine" ce que je m'attendrais à ce que ce soit un peu typique, et "échec du projet" - échec. Y a-t-il même une différence? Est-ce que ce niveau mineur de retard dans la planification constitue un «échec du projet»?

Answer 1

Je pense que la plupart du temps, nous les développeurs, nous oublions que tout ce que nous faisons est, après tout, à propos de bussiness. De ce point de vue, un projet n'est pas un échec alors que le client est prêt à payer pour cela. Tout dépend du client, certains clients ont plus de patience et comprennent mieux les risques de développement de logiciels, d'autres ne paieront pas s'il y a un retard important.

En tout cas, à propos de votre question. Chaque fois que vous développez un projet, il y a des risques, peut-être que vous planifiez la fin du projet à une certaine date, mais cela prendra 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 devez gagner contre les risques que vous prenez. Il y a en fait toute une science appelée "prise de décision" qui l'étudie au niveau du logiciel, donc votre patron n'a pas tort du tout.

Regardons quelques questions, Est-ce que le client est 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 d'achever le projet en assumant les coûts supplémentaires au lieu de jeter tout le travail déjà fait? 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 établir un point et dire, ici, si le projet n'est pas terminé à ce moment-là, c'est un échec. En ce qui concerne votre situation spécifique, qui sait? Votre patron a probablement plus d'informations que vous avez et votre travail consiste à lui dire comment va le projet, combien cela va prendre et combien cela va coûter (en termes d'heures/homme si vous le souhaitez)

Answer 2

Je suppose que le succès du projet dépend du client. Si le client était le directeur de l'entreprise et qu'ils sont heureux, le projet a réussi malgré les échecs en cours.

Answer 3

À moins que les objectifs ont été clairement énoncés au début du projet, il n'y a pas de lignes claires entre «succès» et «échec». Souvent, un projet aurait un degré variable de succès/échec. Pour certains, l'obtention de certains concepts dans le code serait un succès, tandis que d'autres pourraient mesurer le succès en récupérant tous les investissements et en réalisant des bénéfices. Deux modes de défaillance bien connus sont le glissement de programme et la détérioration de la qualité, mais dans le monde réel, les gens ne semblent pas se soucier beaucoup d'eux.

Des façons simples de faire glisser le calendrier sont de laisser les gestionnaires faire une demande quand ils le veulent (fonctionnalités rampantes) et laisser les programmeurs coder tout ce qu'ils jugent correct (codage cow-boy). Processus de gestion des changements tels que sprint planning de scrum et planning game de XP sont quelques-uns des exemples. Thèses sont quelques-unes des tentatives pour la gestion et les développeurs d'expédier des produits fiables à temps. Si l'une ou l'autre des parties ne souhaite pas être fiable ou à temps, la gestion du changement ne serait pas utile.

Answer 4

Andy Rutledge a écrit un article assez intéressant sur le succès. Bien que le titre est Pre-bid Discussions, l'article définit ayant un projet réussi, qui pour Andy implique:

1. Vais-je ou mon équipe être 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 à commencer ce projet?
4. Le client est-il prêt à faire confiance à 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 sa conférence Do the Hustle sur la consultation.

Answer 5

Qu'est-ce que la gestion des modifications et comment s'applique-t-elle à un projet?

La gestion des modifications 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 ...) souhaite ajouter une fonctionnalité, le changement doit être documenté et analysé pour l'effet. Toute modification apportée à la portée, au budget et à l'échéancier 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é de pilotage ou votre client.

Une fois que les modifications ont été approuvées et acceptées, c'est votre nouveau plan. Peu importe le budget ou le calendrier initial.

La gestion du changement sur les projets est entièrement basée sur le principe «pas de surprises».Les bonnes personnes (votre comité de contrôle des modifications) doivent approuver tout changement apporté à la portée, à l'échéancier et au budget avant d'y donner suite.

Une chose à retenir est qu'il peut y avoir certaines contraintes explicites ou implicites et tolérances pour le changement. Vous devrez peut-être livrer votre projet à une certaine date pour satisfaire aux exigences réglementaires du gouvernement. Ou votre organisation peut avoir un seuil qu'une fois le budget du projet est de 30% par rapport au budget initial, il doit aller à un niveau « C » ou le projet est tué. Étudier et énoncer explicitement ces seuils et ces tolérances à l'avance est un bon moyen d'avoir de meilleurs projets.

D'où vient la « gestion du changement » fin, et « l'échec du projet » commencer?

Si un projet répond à la portée approuvé, le calendrier et le budget, alors il est réussi.

Cependant, il peut encore être considéré comme un échec. Les évaluations post-implémentation sont un bon outil pour qualifier cela avec vos parties prenantes (pas seulement votre patron). Aussi Réalisation avantage serait utile de se pencher pour voir en dehors de la boîte noire du projet et l'impact sur l'entreprise dans son ensemble.