02 mai 2015

Mesurer les résultats business de nos projets informatiques n'est pas une évidence

Philippe G., chef de projet informatique dans une banque : Non, nous ne mesurons pas les résultats business de nos projets, il n'y a pas besoin de le faire et ça ne nous gêne en rien. Tout de suite après un projet, il y en a un autre à lancer, et les projets se succèdent. De toute façon, nous sommes à la traîne des besoins des utilisateurs, hélas. Nous sommes trop peu nombreux à l'informatique pour répondre à toutes leurs demandes. Cela fait que, lorsque nous leur livrons une application informatique, ils se jettent littéralement dessus.

Et si s'interroger sur les résultats business des projets, c'était risquer de s'apercevoir qu'on ne travaille pas sur les bons projets ? Ou bien que nos applications informatiques sont utilisées par une faction des utilisateurs à qui elles sont destinées ? Voire, qu'on est trop nombreux à la DSI ?

Cela vaudrait le coup d'ouvrir une cellule d'identification des idées et initiatives avant qu'elles ne deviennent projets, en même temps qu'une cellule d'évaluation des projets côté business.


20 janvier 2014

La décomposition structurée du travail = le juste nécessaire ?

Piloter la collaboration de professionnels épars se fait par des plannings détaillés. Lourds mais puissants. Coûteux en mise à jour. Coût/bénéfice ?

Dans certains cas, le planning détaillé fait obstacle au projet. Le responsable du projet reste scotché à son ordinateur jusqu'à en oublier le terrain, jusqu'à délaisser l'équipe projet. Sans plus de moyens d'être proactif, il en vient n'à voir du réel que les écarts au planifié. Son problème se résume à tenir ses documents à jour. Le cercle vicieux n'est pas loin.

Dans ces cas, précisément, je propose de nous arrêter à la décomposition du travail, quitte à planifier dans le temps, avec précision, les activités de la semaine/des deux semaines à venir, si nécessaire, et seulement celles-là. Finalement, la question-clé que se pose chaque collaborateur pourrait être : quel est mon prochain livrable ? plutôt que : quel est l'enchaînement de toutes les activités ?

Avantages de s'en tenir à la décomposition structurée du travail ? Je laisse au collaborateur le soin de discerner les activités nécessaires à la réalisation du livrable dont il a la charge et je lui fais confiance pour organiser son réseau de collaboration. Je focalise l'attention sur les réalisations concrètes, livrées ou à livrer, le progrès du projet se mesure alors objectivement. J'investis mon énergie sur les livrables, que je dois comprendre, non sur les activités (à propos desquelles, soit dit en passant, je suis techniquement incompétent). J'arrête la décomposition du travail au niveau de détail pertinent à mon niveau, je délègue aux collaborateurs dont je respecte l'expertise et l'autonomie.

Bénéfices de s'en tenir à la décomposition structurée du travail ? Je me consacre à déblayer les obstacles sur le chemin des collaborateurs, ils m'en savent gré, le projet avance, les gens sont heureux.

Les hypothèses et croyances sous-jacentes sont :

  • les collaborateurs du projet sont engagés, motivés.
  • Pour qu'une séquence de travail vive, il faut des collaborateurs vivants.
  • Les gens ont envie de travailler (théorie "X" de Mac Gregor).
  • Avec moins de temps vissé à l'ordinateur, chacun consacrera plus d'énergie aux personnes comme aux livrables. Le cercle vertueux s'enclenche.

Prochaine étape : réviser notre décomposition structurée du travail, telle qu'elle est aujourd'hui, afin qu'elle puisse servir ce propos : délégation à des personnes autonomes. Pourquoi ne pas solliciter nos pairs ?