Failure or Success?

http://blogs.attask.com/blog/strategic-project-management/failure-or-success

Par Ty Kiisel

L’auteur russe et médecin Anton Pavlovich Chekhov a dit une fois : « Il faut être Dieu pour pouvoir distinguer les succès des échecs sans faire d’erreur. »

Quand il s’agit de projets c’est souvent le cas. Récemment, un collègue et moi discutions du rapport « Chaos report » du Standish Group et débattions si leur définition d’échec de projet est réellement valable. Bien que je reconnaisse que si un projet échoue à délivrer la valeur prévue, prend plus long qu’attendu ou coûte plus que budgétisé, je pense certain que l’on doit dire que ce n’était pas un succès – mais cela en fait-il pour autant  un échec ?

Parfois.

Il y a eu quelques échecs très en vue qui se sont avérés ne pas du tout être des échecs. Prenez Christophe Colomb par exemple, il cherchait une route rapide vers l’Inde et a trouvé le Nouveau Monde. Avait-il réussi à trouver l’Inde en passant par l’Ouest, Non. Est-ce que c’était un échec ?

Parfois je pense que les projets sont condamnés à rencontrer la définition du Standish Group dès le début. Les parties prenantes et sponsors ne sont pas clairs sur leurs attentes, on handicape les leaders de projet avec des chronologies peu réalistes et des équipes projet  tristement à court de personnel. Quand ces conditions existent, peut-on s’étonner qu’une équipe projet lutte pour frapper une cible mouvante avec un arc et une flèche brisés ?

Avec ceci en mémoire, laissez-moi faire deux ou trois suggestions qui pourraient aider à éviter à vos projets la catégorie « échec » (au moins selon la définition du Standish Group) :

1. Définissez le succès : Cela semble assez simple, peut-être même trop simple. Néanmoins, sur combien de projets avez-vous été qui n’avaient pas une définition claire de ce que le succès serait avant de commencer ? Imaginez passer un ballon dans un panier qui serait déplacé aléatoirement pendant le jeu. C’est difficile pour les équipes projet de frapper une cible mouvante.

2. Si le contenu change, la définition de succès devrait faire de même : Je ne suis pas un grand fan des changements bon gré mal gré dans le périmètre d’un projet, mais si il y a de bonnes raisons (autre que l’équipe essaie de réduire les besoins pour respecter les délais – ce qui indiquerait « échec » à mon avis) de changer le périmètre ou les besoins, il n’est pas exact d’appeler le projet un échec s’il coûte plus ou prend plus longtemps à finir.

3. Soyez honnête et engagez l’équipe dans les estimations de ressources : Des délais arbitraires n’ont simplement aucun sens et devraient être évités à tout prix. Une des choses que j’aime dans la méthodologie Scrum est la réunion de planification de Sprint. L’équipe estime les besoins en ressources et s’approprie leurs estimations. Pour des chefs de projet, ce type d’approche me signifie quelque chose. Ceux qui sont les plus proches du boulot le comprennent le mieux et devraient être impliqués dans les décisions sur l’échéancier. Qui plus est, donner au chef les délais qu’il ou elle veut parce qu’il ou elle les veut n’est pas une bonne idée si ce n’est pas réaliste – et dirige l’équipe vers un échec.

4. Bâtissez la bonne équipe: Juste parce que quelqu’un est disponible ne signifie pas qu’il est la bonne personne pour l’équipe. Je sais que beaucoup de chefs de projet n’ont pas le luxe de choisir leur équipe, mais ils peuvent exercer une influence sur qui fait ou pas partie du groupe.

Bien sûr, il n’y a aucune solution miracle pour échapper à la catégorie « échec ». J’ai participé à des discussions qui suggèrent (pour certaines raisons) que les informations du Chaos Report seraient imprécises. Même si en réalité les résultats sont 50 pour cent meilleur qu’annoncé dans ce rapport, c’est toujours trop d’échecs. En tant que leaders de projet, notre travail est d’obtenir que des choses soient faites avec succès.

Cela étant dit, que faites-vous pour assurer le succès de votre projet ?

Sur le même sujet, de l’échec, j’ai bien aimé cette vidéo sur l’importance d’éliminer la peur de l’échec. Sans échec pas de création, peu d’innovations, et donc peu de projets réussis !

« What would you attempt to do if you knew you could not fail? »