Projet ayant échoué: quand l'appeler?

Il y a quelques mois, mon entreprise s'est retrouvée entre les mains face à l'urgence d'un projet chauffé à blanc et toute mon équipe de six personnes a essentiellement tiré une «semaine de crise» de cinq semaines. Au cours des 48 heures précédant la mise en service, j'en ai travaillé 41, dont deux nuits consécutives. Au milieu de cela, j'ai publié ce qui a été ma question la plus réussie à ce jour .

Pendant tout ce temps, il n'a jamais été question d'échec. C'était toujours "faire avancer les choses, quelle que soit la douleur".

Maintenant que la chose est terminée et que nous, en tant qu'organisation, avons eu le temps de nous asseoir et de faire le bilan de ce que nous avons appris, une question m'est venue à l'esprit. Je ne peux pas dire que j'ai déjà participé à un projet que je dirais avoir "échoué". Beaucoup qui étaient en retard ou au-dessus du budget, certains de façon désastreuse, mais j'ai toujours fini par livrer QUELQUE CHOSE.

Pourtant, j'entends constamment parler de "projets informatiques ayant échoué". Je me demande ce que les gens en pensent. Quels étaient les paramètres qui définissaient «l'échec»? Quel était le contexte? Dans notre cas, nous sommes une boutique de logiciels avec des clients externes. Un projet interne à une grande entreprise a-t-il plus d'espace pour «échouer»? Quand faites-vous cet appel? Que se passe-t-il lorsque vous le faites?

Je ne suis pas du tout convaincu que faire ce que nous avons fait soit une décision commerciale intelligente. Ce n'était pas mon appel (je suis juste un singe de code) mais je me demande s'il aurait été préférable de réduire nos pertes, de dire que nous ne livrons pas et de passer à autre chose. Je ne dis pas seulement qu'en raison de la piqûre des longues heures - l'entreprise a royalement perdu sa chemise sur le projet, plus les coûts intangibles pour l'entreprise en termes de moral et de fidélité des employés étaient importants . Facteur qui contre le coup PR de ne pas livrer un projet de haut niveau comme celui-ci était ... et je ne sais pas quelle est la bonne réponse.

Le concept d'échec est vraiment un appel lié aux affaires. Si un projet commercial coûte plus cher que l'argent qu'il rapporte, ce projet sera considéré comme un échec. Si un projet open source ne peut pas créer une communauté autour du code pour aider à le maintenir et à en prendre soin, ce projet open source a échoué.

J'ai été impliqué dans des projets où nous avons tout livré à temps et dans les limites du budget, mais l'équipe de développement commercial n'a pas réussi à suivre le travail. D'un point de vue commercial, le projet a échoué, bien que ce que nous avons livré ait été bien reçu et apprécié.

Dans des situations comme la vôtre, l'entreprise doit prendre des décisions difficiles. S'ils veulent que le projet réussisse, ils doivent apprendre quelques leçons:

• Si vous ne planifiez pas correctement, cela entraînera un stress excessif pour votre équipe et, en fin de compte, entraînera l'échec d'un projet.
• Une équipe stressée exercera des représailles avec un taux de roulement élevé - et, finalement, vous ne pourrez pas amener de bonnes personnes à rejoindre l'entreprise.
• Des urgences se produisent, mais trouvez la cause de l'urgence et changez vos pratiques pour éviter cette urgence à l'avenir.

Toute entreprise qui n'apprend pas de ses erreurs répétera l'histoire assez souvent. Je considérerais cela comme un signe qu'il est temps de trouver une autre entreprise.

L'échec est tout ce qui peut décrire un objectif non atteint.

En bref, lorsque vous définissez votre objectif, vous définissez également ce qu'est un échec dans ce contexte.

Dans la littérature que vous mentionnez, un échec est un projet dépassant le budget et / ou n'ayant pas respecté le délai .

Cela ne signifie pas que le produit ne sera pas utilisé. Cela signifie qu'il a été développeur avec beaucoup plus de douleur, d'argent et de temps que prévu.

When you should cancel a project? Lorsque vous êtes sûr que chaque nouvelle seconde dépense vous rapportera moins de valeur que son coût.

C'est ce qu'on appelle le dilemme des coûts irrécupérables .

Si le sujet vous intéresse, je vous recommande la Marche de la mort d' Edward Yourdon . Un très bon livre.

Il existe de nombreuses façons dont un projet peut «échouer». Et bon nombre sur lesquels j'ai travaillé ont été des échecs:

1. Le logiciel sous film rétractable a dû être réécrit pour répondre aux nouvelles règles statutaires / réglementaires. Les mauvais gestionnaires ont choisi d'éviter d'embaucher de nouvelles personnes pour aider avec la charge de travail, et surtout avec les compétences qui nous manquaient tous. Le produit ne possédait pas les nouvelles fonctionnalités requises (il fallait faire le dépôt électronique d'une certaine manière) et devait être retiré du marché. Bien que ce produit ait généré environ 5% des revenus de notre bureau, un changement réglementaire similaire arrivait qui a affecté le produit qui a généré 60% de nos revenus. Les développeurs ont pris sur eux d'acquérir les compétences nécessaires, mais les mauvais gestionnaires ont choisi d'attendre qu'il soit presque trop tard pour commencer à mettre en œuvre les changements requis. Nous avions 3 ans pour avertir que ces changements arrivaient alors que nous tentions de soumissionner du côté serveur de ce changement réglementaire - et les entreprises nous ont à juste titre interdit de soumettre l'offre. Nos mal-gestionnaires ont choisi de nous faire attendre 8 mois avant le basculement avant de pouvoir y travailler.

2. Le projet dépassait déjà le budget et était en retard lorsque j'ai été amené à aider à le terminer. Les gestionnaires de plusieurs niveaux supérieurs ont décidé que les coûts irrécupérables étaient déjà trop élevés pour faire le retour sur investissement requis pour le projet, de sorte que le projet a été annulé et toutes les personnes impliquées ont été licenciées. Travailler là-bas pendant 1 semaine avant que le groupe ne soit mis à pied (y compris moi) a été le temps le plus court que j'ai jamais travaillé dans un endroit.

3. Le projet interne a pris tellement de temps à s'achever que le sponsor du projet avait acheté un logiciel standard (dans ce cas Microsoft Office) et écrit son propre VBA pour faire son travail. Le chef de l'équipe de développement a continué de promettre la lune et a refusé d'écouter lors des réunions de direction que le projet avait déjà été annulé. 6 personnes ont travaillé pendant environ un an pour terminer un système qui n'allait jamais être utilisé.

Le seul projet avec lequel j'ai été impliqué en tant que programmeur ou faisant partie de l'équipe PM était Ricochet, qui a fait faillite avec la faillite de Metricom . Il y avait littéralement des milliers d'entrepreneurs à travers le pays qui y travaillaient. Lorsque leur directeur financier a démissionné, le projet s'est littéralement arrêté. Les meubles ont commencé à être retirés des bureaux au fur et à mesure de la liquidation.

Pour beaucoup d'entre nous, le terme applicable était «chômage», mais Lame Duck serait une description adéquate. Souvent, les personnes clés devront rester jusqu'à ce qu'un processus d'autopsie / liquidation soit terminé, tout comme certains politiciens qui restent en poste pendant quelques mois pour terminer leur mandat avant l'arrivée de leur successeur.

Comme Otávio Décio l'a indiqué, je n'ai pas vu un projet échouer au point d'être abandonné depuis le boom des dot com.

Il s'agit d'un problème courant, également mentionné dans certains livres sur la gestion de projet. Aucun projet n'échoue jamais, même s'il ne propose qu'une expérience «à éviter la prochaine fois».

OMI, un projet est un échec sinon le faire aurait été moins cher. Par exemple, si le produit a une durée de vie prévue de 5 ans et économise 100K par an à l'entreprise, alors c'est un échec s'il a fallu plus de 500K pour le fabriquer. (Je triche avec les taux d'intérêt ici pour le simplifier). Certaines personnes affirment que chaque projet avec un dépassement de coût et / ou de temps est un échec, mais l'OMI cette définition n'a pas de sens car elle se concentre trop sur des estimations et une planification correctes.

Je n'ai également jamais participé à des projets "ayant échoué" - mais beaucoup de projets avec des dépassements de coûts et de temps. Je crois que le problème est qu'aucune des parties - le client ou l'entrepreneur - ne veut qu'un projet soit considéré comme un échec pour tous les enfants pour des raisons, y compris la responsabilité.

Je pense donc que lorsque vous entendez des «projets informatiques ayant échoué», ce sont en réalité des «projets qui ont dépassé leurs limites, soit dans le temps, soit dans le budget».

Après tout - combien de personnes ou d'entreprises que vous connaissez viendraient net et diraient «nous avons échoué»?

Pourtant, j'entends constamment parler de "projets informatiques ayant échoué".

Quels étaient les paramètres qui définissaient «l'échec»?

C'est un terme péjoratif souvent utilisé lorsque le projet change. Beaucoup de gens aiment qualifier le changement d '"échec". Je ne sais pas pourquoi, mais cela les rend plus puissants ou plus importants pour avoir identifié un échec.

Certains projets sont vraiment de l'argent perdu et rien de valeur n'est créé. Mais ce sont rares.

Même un projet qui n'a jamais fourni de logiciel fonctionnel est une expérience d'apprentissage de ce qu'il ne faut pas faire. Cela a créé de la valeur. Il a créé une valeur imprévue, il peut donc être étiqueté de la façon dont les gens veulent l'étiqueter. "Échec" est aussi bon que "A appris quoi ne pas faire" dans certains cercles.

La vraie question est "la valeur était-elle proportionnelle au coût"? Et même alors, la valeur peut être si difficile à mesurer que la réponse est entièrement politique ou subjective.

Un projet interne à une grande entreprise a-t-il plus d'espace pour «échouer»?

Peut-être. «échec» est un terme politique. Toute modification du calendrier, du budget ou de la portée peut être étiquetée comme «changement» ou «échec». Ils peuvent également être étiquetés comme «ont appris quelque chose d'important sur l'incapacité de notre équipe à écrire un serveur Web». Ou, encore plus positivement, "nous avons appris les compétences dont nous avons besoin avant de réessayer."

Les projets externes sont souvent davantage supervisés par les vendeurs et les livreurs, les comptables et la gestion de projet. Les projets internes ont souvent moins de contrôle.

Quand faites-vous cet appel? Que se passe-t-il lorsque vous le faites?

Quand il est opportun que quelqu'un fasse pression sur l'organisation parce que vous n'êtes pas d'accord avec lui. Vous étiquetez leur projet comme «échec» et les faites réaffecter afin que vous puissiez avoir différentes personnes.

La seule façon dont un projet peut être un échec total est la fraude criminelle - où aucune leçon n'a été tirée, rien ne peut être amélioré, et les criminels ont été limogés et emprisonnés, laissant l'organisation ignorante de ce qui s'est passé.

Sinon, il y a toujours une valeur.

La vraie question est "la valeur était-elle proportionnelle au coût?"

Donc, votre entreprise qui facturait ce travail, vous et 5 autres personnes ont travaillé à mort pendant 5 semaines. Ils tirent toujours profit de votre travail acharné. J'espère que vous avez quelque chose, car la sécurité de l'emploi n'est plus de nos jours et il y a beaucoup de travail. (Prise sans vergogne contactez-moi si vous avez besoin de travail et êtes un programmeur compétent, je connais plusieurs endroits qui ont désespérément besoin d'aide).

Cela dit, si votre entreprise devait réellement vous payer pour tout ce travail et les 41 heures avant la mise en service, elle aurait PERDU de l'argent.

Votre direction a besoin de s'asseoir et d'expliquer que si cela se reproduit, vous serez payé. Ils doivent faire un meilleur jugement quant au moment de retirer la fiche.

Moi aussi, comme de nombreux intervenants ici, j'ai été impliqué dans plusieurs grands projets qui se sont déroulés dans le temps et le budget - un de plus d'une demi-décennie. Le pire scénario (celui d'une demi-décennie) impliquait une folie gratuite du Mois de l'homme mythique, ainsi qu'un fluage de portée épique. Cela dit, il n'a jamais été abandonné et ils commencent à accepter certains clients maintenant. Mais les attentes initiales (remplacement propre et bien conçu d'un ancien système obsolète) et un budget et un calendrier relativement modestes - sont depuis longtemps brisés.

De plus, contrairement à la plupart des gens ici, j'ai également vu un projet totalement échouer - au point d'être abandonné . Le dernier clou dans le cercueil est arrivé début 2010. C'était le scénario:

Petite entreprise (environ 30 personnes) proposant des solutions ERP personnalisées pour les moyennes entreprises. Ils avaient quelques installations logistiques relativement lucratives avec des sociétés minières australiennes et quelques équipements de camionnage aux États-Unis. La plate-forme était un cadre interne personnalisé construit sur J2EE. En fait, relativement personnalisable et bien fait - de nouvelles installations simples peuvent être construites assez rapidement, mais elles ne se développent pas trop bien lorsque le niveau de personnalisation requis est très complexe (comme c'était le cas pour certains de leurs plus gros clients).

En bref: certaines de leurs installations les plus importantes et les plus prestigieuses ont fonctionné dans le temps et le budget, et il semble que le marché n'ait pas apprécié cela, de sorte qu'ils n'ont pas pu obtenir plus de clients. La société était essentiellement un poney à un tour, ne faisant guère plus que ce système ERP, donc une fois que les flux de trésorerie de celui-ci se sont taris, ils ont cessé leurs activités et le système a été abandonné (le GFC aurait peut-être aussi joué un rôle) .

(Je n'y ai travaillé que pendant 9 mois - en 2004/2005. Ils ont essentiellement embauché et rendu superflu au fur et à mesure que la charge de travail allait et venait avec de nouvelles installations - au lieu d'embaucher des entrepreneurs - ce qui est assez douteux. Avec le recul, l'échec était probablement plus à faire avec un modèle commercial floconneux qu'avec la technologie.)

Si le projet était déployé de manière à ce que la demande d'origine soit satisfaite, je qualifierais le projet de réussi. Pour moi, un échec serait de déployer une application qui a ensuite été universellement rejetée par les utilisateurs finaux car elle ne répondait pas à leurs besoins. Ou, pire encore, le projet prend fin avant qu'un produit ne soit réellement déployé auprès des utilisateurs et que leurs besoins ne soient pas satisfaits.

Généralement, si une entreprise travaille pour un client externe, ce n'est pas sa décision de retirer un projet car il peut y avoir des problèmes contractuels (par exemple, rupture de paiement du contrat) ou un coup PR majeur, comme vous l'avez noté. Dans certains cas, s'il y a une pénalité pour rupture de contrat, le coût de la fin du contrat est plusieurs fois inférieur à celui de la rupture du contrat et la perte d'une somme symbolique est l'option préférée.

À long terme, une entreprise peut travailler à améliorer le moral des employés pour compenser un temps critique pendant un projet ou remplacer les employés qui sont partis parce qu'ils ont été poussés à rude épreuve, mais il peut parfois être impossible pour eux de se remettre des échecs majeurs du projet ( c'est-à-dire regarder les sociétés de jeux qui n'ont pas livré leurs produits à temps et qui ont fait faillite)

Lorsque l'analyse de rentabilisation ne tient plus.

C'est la mesure que Prince2 (la méthodologie de gestion de projet) utilise et cela a beaucoup de sens pour moi.

Essentiellement, il est dit à la fin de chaque étape du projet, ou si un projet ne respecte pas certaines tolérances dans certains domaines (calendrier, coût, qualité), il devrait y avoir un examen de l'analyse de rentabilisation. À ce stade, vous dépassez les coûts totaux prévus et les avantages réalisables en fonction de ce que vous savez maintenant et si le projet ne se cumule plus, il est tué.

Le problème avec cela pour de nombreux projets que j'ai vus est qu'ils ne précisent pas ce qu'ils essaient de réaliser en détail à l'avance, ce qui rend très difficile d'évaluer (a) si c'est toujours réaliste, ou (b ) si les coûts que vous allez dépenser pour y arriver en valent la peine. Dans ces situations, la meilleure chose que vous puissiez faire est de produire une analyse de rentabilisation au moment où vous devenez suspect pour vous permettre de comprendre si vos soupçons sont corrects.

Préparer une analyse de rentabilisation ne doit pas être une entreprise majeure, deux côtés de A4 suffiront. Les coûts sont relativement faciles (à titre de mesure approximative, un programmeur coûte: (salaire annuel * 2) / 250 par jour pour l'Europe, probablement un peu moins pour les États-Unis car les avantages sont plus faibles et le nombre moyen de jours ouvrables plus élevé, qui sont les intrants ici ).

Les avantages sont plus difficiles, mais si vous estimez de manière aussi pessimiste avec autant de précision que possible, alors si l'analyse de rentabilisation ne se cumule pas (normalement mesurée car elle doit générer un rendement de x% sur ses coûts sur 3 ans, où X est susceptible d'être de 50% ou donc) vous pouvez le regarder plus en détail. N'oubliez pas les coûts de licence et de matériel (même si vous utilisez du matériel existant car cela signifie qu'il ne peut pas être utilisé pour autre chose une fois que vous l'avez pris) et une assistance continue.

Mais beaucoup de choses ne sont pas des programmeurs, c'est du PM et l'entreprise devrait le faire avec la contribution de toute l'équipe du projet.