Les projets IT ont mauvaise presse.

Les enquêtes le montrent, les projets IT peinent à donner un résultat satisfaisant dans de nombreux cas.

Qu’ils s’agissent de trop promettre de choses ou plus simplement de ne pas atteindre un niveau minimum de résultat, il y a tout un éventail d’effets possibles.

Pourquoi les projets IT échouent ?

Les raisons les plus communes sont simples :

-> trop grande abstraction du besoin

Je pourrais également formuler ça comme un manque de précisions dans le résultat attendu. Je dis bien résultat, pas fonction ou fonctionnalités.

L’origine de ce problème peut se trouver dans plusieurs élements. Tout d’abord l’utilisation de méthodes mal maitrisées. Je ne sais pas si vous avez déjà travaillé dans un projet où tout doit être fait en UML et où la moitié des acteurs ne connaissent pas vraiment la notation. Le résultat est très approximatif. La méthode doit être simple et comprise par les acteurs clés.

Je pense que sur ce point, il ne faut pas hésiter à se faire aider.

Ensuite, le manque de temps pousse les acteurs du projet à survoler les questions. Réduisez le périmètre ou prenez plus de temps.

Un autre écueil fréquent : faire 2 ans d’analyse et se rendre compte que la méthode n’est pas adaptée.

Lorsque l’abstraction du besoin est trop grande, l’analyse n’est pas terminée. La conséquence directe de ça, c’est que les gens du terrain, quelque soit leur niveau hiérarchique, vont rejeter le projet : il ne parle pas de ce qu’ils font !

-> approche big bang

Comme tous les consultants, j’aimerais pouvoir arriver quelque part et résoudre tous les problèmes d’un coup.

Le temps de réponse aux clients est trop long ? Hop ! Voici le nouveau processus à suivre dès demain ! Et Hop, voici le nouveau SI pour appuyer le tout !

Malheureusement, les choses ne marchent pas ainsi. S’il est important de savoir où on veut aller, il ne faut surtout pas croire ou vendre le fait que l’idéal sera atteint en un rien de temps.

L’approche big bang ne marche que dans des cas très restreints (taille d’équipe réduite, changement contraint par la législation).

Dans la vraie vie, les choses mettront toujours plus de temps que prévu.

N’oubliez pas que l’élément principal à préserver pendant le projet, c’est la productivité actuelle de l’organisation : qu’elle soit bonne ou pas !

-> responsabilité diluée

Ce n’est peut être pas très populaire, mais tout projet doit avoir une organisation définie. Savoir qui fait quoi est un premier pas. Savoir qu’est-ce qui est attendu de qui est une seconde étape. Ceci est surtout vrai lorsque il s’agit de travailler avec des personnes externes à l’organisation : prestataires, éditeurs.

Plus le projet est gros, plus la responsabilité est diluée. Plus le projet est gros, moins les responsables vont se préoccuper de ce qu’il y a en dehors de leur domaine.

C’est un ajustement délicat à faire mais l’organisation et le nombre de responsables doit correspondre à la taille du projet. Il vaut mieux avoir plus de coordination à faire entre 3 projets avec des frontières claires que d’avoir à gérer un gros projet où chacun ne s’occupe que de son silo.

-> management inadapté

S’il y a de l’enthousiasme, il faudra l’entretenir. S’il y a des attentes, il faudra y répondre. S’il y a des inquiétudes, il faudra rassurer. La technologie reste minoritaire dans l’aboutissement de la plupart des projets.

Bien souvent, il s’agit de canaliser et d’écouter les gens. Il faudra éviter de passer pour une girouette en changeant de direction tous les mois. Personne n’aime travailler pour rien. Même si des gens dans les équipes peuvent avoir des réflexions du style « je suis quand même payé, ça m’est égal », c’est bien entendu une réaction de dégoût plus qu’un véritable état d’esprit.

Nous voulons tous être reconnu pour ce que l’on fait, contribuer à quelque chose de plus grand que nous et accomplir quelque chose. Le management doit aller dans ce sens et changer radicalement d’orientation plusieurs fois peut tuer la motivation intrinsèque de votre équipe.

Pour finir sur une note positive

-> Prenez une méthode simple et pratique

-> Améliorez les choses petit à petit

-> Définissez une taille de projet gérable et des responsabilités claires

-> Adoptez un style de management proche du terrain

Popularity: 3% [?]