7 facteurs pour un échec garanti

N'appréciez pas les employés, ne sous-estimez pas la complexité ou ne vous fiez pas aux mythes. Si ces facteurs et d'autres sont pris en compte, votre projet est assuré d'échouer.

Sais-tu cela? Pendant des semaines et des mois, le chef de projet rend compte de son projet. Bien sûr, les lampes d'état classiques ne devraient pas manquer. Et c'est constamment sur le vert : tout va bien. Mais un jour, le feu passe soudainement au rouge ! Par conséquent, un processus de traitement très désagréable commence pour les responsables. La plupart du temps la première question porte sur le coupable, la seconde sur les causes, puis on ne se consacre qu'aux solutions possibles.

Vous trouverez ci-dessous 7 facteurs typiques qui garantissent presque l'échec.

Facteur 1 : ne pas tenir compte du facteur humain

Pendant de nombreuses années en tant que développeur, chef de projet, coach et gestionnaire de crise, j'ai constaté que les tensions interpersonnelles sont le plus grand obstacle à la mise en œuvre de projets informatiques. A l'inverse, l'alchimie entre les collaborateurs est correcte et il y a un climat ouvert, tolérant aux pannes, des solutions peuvent être trouvées à toutes les difficultés – même dans les situations critiques.

Il est dans la nature de l'homme d'éviter les conflits. Et il est donc naturel que les gens (par exemple le chef de projet) l'ignorent complètement ou détournent le regard trop longtemps. Mais les conflits ne se dissolvent généralement pas d'eux-mêmes. La recherche s'impose, comme la modération et au moins le recul sur le changement ou la solution.

Parfois, ce sont les petites choses qui ont un grand impact, comme un nouvel emploi pour un employé. Cependant, des dépenses plus importantes sont souvent nécessaires, comme la réorganisation des équipes, pour ramener la paix dans le projet. Cependant, la pire alternative est de ne pas tenir compte du facteur humain.

Facteur 2 : Pensez trop grand ou faites trop petit

Certaines entreprises reprennent un projet. Ils sous-estiment la complexité, les risques et l'immense effort personnel et matériel. Indépendamment des coûts, mon organisation est-elle même capable de gérer un projet avec 100 employés ? Avons-nous suffisamment d'emplois, de salles de réunion, de capacité réseau, de serveur de développement, etc. ?

L'entreprise est-elle en mesure de répondre aux exigences d'une grande équipe de développement agile sur une piste de développement et de test incluant l'intégration/livraison continue ? Prédit de telles questions, l'analyse de rentabilisation aurait dû être calculée de manière réaliste. J'ai vu à plusieurs reprises qu'il est devenu clair peu de temps avant le début d'un projet gigantesque que le système résultant n'était en fait pas nécessaire car il ne correspondait pas au modèle commercial de l'entreprise. Malheureusement, personne ne l'avait remarqué auparavant.

Autre schéma reconnaissable : Un protagoniste veut absolument réaliser un TS, par exemple pour des raisons de prestige ou pour utiliser des salariés, et calcule les coûts comme négligeables. Si le chef de projet ultérieur n'est pas assez fort pour présenter l'écart dans le cadre des instances décisionnelles, cela crée un potentiel de crise élevé.

Facteur 3 : se fier à 100 % aux estimations et à la planification

Un mythe répandu est la fiabilité des estimations et de la planification. Le concept du projet est défini par son unicité. Peut-être y avait-il déjà des projets similaires, mais en principe, une entreprise entre dans un nouveau territoire à chaque projet. Cela signifie que les estimations ne peuvent être qu'aussi bonnes que les expériences des créateurs et leurs capacités d'adaptation concernant le projet en cours.

Cependant, les plans ne peuvent jamais inclure des événements spontanés, des changements en termes d'exigences, de technologies ou l'entrée de risques imprévus. En fin de compte, les estimations et les plans qui en découlent ne sont rien d'autre qu'un pari sur l'avenir ! Accepter ce fait est un premier pas en avant. La discipline, le courage et le système aident à prévenir ou à soulager d'éventuelles crises.

Facteur 4 : Le triangle magique PM constamment ignoré

Études d'informatique, premier semestre, premier cours gestion de projet : « Le triangle PM magique« . La personne intéressée par les tâches de gestion est initiée très tôt aux lois de ce triangle. Celles-ci disent que le changement de l'un des trois paramètres entraîne inévitablement les conséquences d'au moins un des autres paramètres.

Cependant, ces lois ne sont que trop heureuses d'être ignorées dans la pratique. Comme déjà mentionné dans le contexte de l'estimation et de la planification, un projet est quelque peu unique et la probabilité d'influences imprévues est exceptionnellement élevée. C'est pourquoi, tôt ou tard, il est nécessaire pour presque tous les projets que les responsables réagissent à ces influences. Cependant, si tous les paramètres sont fixes, c'est-à-dire que le client continue d'exiger le respect du temps, du budget et du contenu, l'échec n'est qu'une question de temps.

Facteur 5 : Documentation de tout

Free d'après Franz Beckenbauer : "On appelle ça un classique !" Bien que de plus en plus d'entreprises s'appuient sur des procédures agiles (principalement scrum), on trouve encore des organisations et des projets qui accordent plus d'importance à une documentation complète qu'au logiciel à créer. Il s'agit d'un risque élevé, en particulier dans les grands projets. Souvent, une chasse aux consultants et experts du département sur des milliers de pages a souvent fonctionné pendant des mois voire des années, qui seront ensuite traduites par une autre équipe de SW.

Plus la documentation est étendue, plus le temps de réalisation est long et moins il est probable que le SW corresponde aux besoins réels des utilisateurs. Les réactions aux changements du marché ne sont pas possibles ou ne sont possibles qu'avec beaucoup d'efforts et des concessions temporelles. Un document offre une base sur laquelle le produit peut être retiré. Malheureusement, ce qui est écrit n'est pas forcément clair et le résultat est différemment pensé qu'à l'origine. Combien de fois ai-je entendu la phrase du personnel du service et des utilisateurs finaux : "Oh, je l'imaginais très différemment !" .

Facteur 6 : simplement pas d'organisation de projet équilibrée

Une équipe de 20 développeurs et 1 contact technique ? Il n'est pas nécessaire d'avoir des connaissances spécialisées pour reconnaître que cette construction échouera tôt ou tard. Au début d'un projet, qu'il soit en cascade ou agile, cela peut encore fonctionner car les développeurs sont occupés avec les frameworks ou la mise en place des environnements. Mais très bientôt les employés poseront des questions – besoin d'un soutien professionnel intensif.

Un expert en la matière ne peut jamais résister à cette pression temporelle et émotionnelle et a besoin d'un soutien, à la fois en termes de personnel et tout au long du processus de mise en œuvre. Cependant, c'est une très mauvaise idée de contrer le goulot d'étranglement du personnel avec la restriction de la communication.

Une idée aussi populaire et très frontale sur l'échelle des erreurs de gestion typiques : un employé recueille les questions des développeurs, en discute avec l'interlocuteur technique, et renvoie les réponses. De cette façon, vous créez un goulot d'étranglement par excellence, déclenchez un taux d'erreur extrêmement élevé et retardez considérablement le développement.

Facteur 7 : Chauffez la grenouille lentement

Connaissez-vous cette histoire ? Si vous mettez une grenouille dans une casserole avec de l'eau et que vous la chauffez continuellement jusqu'à la cuisson, la grenouille n'essaie pas de s'échapper. Si vous le jetez directement dans l'eau chaude, il saute immédiatement.

L'une de mes connaissances les plus importantes sur moi ces dernières années est que les employés des projets informatiques expirent avec une durée croissante d'aveuglement croissant. Les processus une fois établis sont peut-être remis en cause dans les rétrospectives, mais rarement vraiment drastiques. La capacité des personnes à réagir aux changements disparaît de manière proportionnelle à la durée d'un projet.

Par conséquent, un éclairage sporadique (bilans de santé) est recommandé par des projets (énormes) par un consultant externe, auparavant non impliqué, afin de découvrir les fuites, les chemins potentiellement non ciblés. Au plus tard après avoir reconnu une crise généralisée, il est presque impossible de créer le redressement avec le personnel existant seul.

Donc c'est possible

Les erreurs de gestion typiques décrites ne sont qu'une petite sélection de ma liste personnelle de modèles de comportement, qui empêchent ou même empêchent la réussite des projets de développement SW. De loin, on pourrait avoir l'impression qu'il est facile de reconnaître les problèmes et de les corriger dès les premières étapes des projets. Mais les conditions-cadres supposées inamovibles et l'aveuglement évoqué rendent souvent difficile la prise des bonnes décisions. Les statistiques du Standish Group dit au début le démontrent année après année.

Si un projet est en difficulté, il est fortement recommandé qu'un gestionnaire de crise externe puisse analyser et agir avec objectivité, sans sensibilité et sans le lest de l'historique du projet. La seule participation d'un expert à l'écoute des gens dans le projet peut déjà avoir des effets positifs. La sélection de mesures adaptées réussit aussi la transformation et finalement le retournement.