Le temps n’est pas loin où l’on se posera la question de réinventer la gestion de projet afin de se focaliser sur le fait de délivrer une réponse à un besoin et non plus de considérer comme trop souvent le projet comme étant sa propre fin. Quand se rend on compte qu’un projet est sa propre fin ? Lorsqu’on livre au final quelque chose qui correspond en tout point au livrable défini au tout début pour se rendre compte que le besoin a évolué ou que ce a quoi le client interne ou externe a dit oui ne correspond pas vraiment à ce qu’il attendait, problèmes de communication, mauvaise connaissance du champ des possibles et mauvaise qualité des échanges obligent.
A côtoyer des développeurs à longueur de journée je me suis intéressé à la manière dont ils travaillent et j’ai comme l’impression que ces gens ont découverte une sorte de Graal nommé méthodes agiles.
Bien sur il n’a pas fallu longtemps pour me demander si c’était applicable à des projets autres que le développement logiciel.
Les quatre valeurs de ce type de méthodes, si je m’en réfère à wikipédia me semblent bien adaptées à nombre de projets :
- L’équipe (« Personnes et interaction plutôt que processus et outils »)
- L’application (« Logiciel fonctionnel plutôt que documentation complète »)
- La collaboration (« Collaboration avec le client plutôt que négociation de contrat »)
- L’acceptation du changement (« Réagir au changement plutôt que suivre un plan »)
Il me semble bien que très peu de travail suffirait pour réécrire cela afin que que cela s’applique de manière plus générale. Je crois notamment beaucoup à la multiplication des iterations, à l’échange permanent, à l’implication permanente du client (interne ou externe) et au fait de mettre les choses en places peu à peu, même de manière parcellaire, pour voir ce que cela donne.
Pour avoir tenté une expérience similaire sur un projet ou il était quasi impossible de réunir tout le monde plus d’une fois par mois et où les gens se connaissaient peu et en utilisant les bons outils pour échanger en asynchrone et permettre à chacun de donner en permanence de la visibilité aux autres sur ce qu’il faisait, les problèmes rencontrés, les questions qui se posaient, le tout avec des personnes plutôt habituées à des méthodes plus « classiques » j’ai été impressionné par le résultat. Tout a été fait dans les temps, alors même que comme vous l’avez compris on partait d’assez loin, avec une équipe disparate déjà surbookée par ailleurs, et dont les membres se connaissaient. Une discussion et des intéractions permanentes plutôt que des points d’étapes séparés par de longs tunels de solitude.
Vu les circonstances on m’avait passé le mot : « on se focalise sur l’essentiel et on laisse du mou sur le reste afin d’avoir assez de marge pour s’adapter en permanence ». Le contexte était donc favorable et franchement le jeu en valait la chandelle car a posteriori je ne sais pas comment on aurait pu faire autrement.
Un embryon d’expérimentation fort concluant donc.
Bref quelque chose à creuser et à formaliser. D’autant plus que si j’en crois ce qu’en dit Frédéric de Villamil, tout ce qui fait qu’une équipe n’est pas prête pour les méthodes agile ressemble fort aux symptomes de l’entreprise qui peine à s’en sortir dans un contexte d’incertitude, de discontinuité, de disruption (dommage, c’est le monde dans lequel nous vivons).
Vous êtes inflexible : apôtre du « on a toujours fait comme ça » vous ne concevez pas de changer votre manière de faire quels que soient les événements.
Vous détestez l’incertitude : mieux vaut prévoir un délais intenable que laisser de la marge, mieux vaut livrer quelque chose qui ne convient pas plutôt qu’apporter des modifications en cours de route. Peu importe si on sait par expérience que ça ne passera pas, avoir décidé au départ que ça passerait vous rassure car vous donne l’illusion de maitriser.
Vous traitez vos collaborateurs comme des ressources dont vous oubliez qu’elles sont humaines. La notion de talent vous est étrangère, vous ne voulez que des hommes machines interchangeables, des clones et qu’aucune tête ne dépasse.
Vous considérez le projet comme un processus linéaire : vous vous refusez à accepter que les impondérables existent ni que les choses puissent être améliorées. Les choses se passent forcément comme vous l’avez décidé et dans le cas contraire c’est la faute des autres. Et bien sur vous n’apprenez pas des échecs et opérerez exactement de la même manière la prochaine fois.
Vous connaissez des applications « institutionnalisées » de ces méthodes hors du domaine du développement logiciel ? Mes recherches m’ont permis de trouver beaucoup de références sur ce que les personnes concernées appellent « Gestion de Projet 2.0 » (fallait y penser) mais aucun exemple d’utilisation généralisée.
Qu’est ce que cela vous inspire ?
Entrées similaires:
Les réseaux sociaux externes ne servent pas qu’au marketing
Tendances outils collaboratifs en 2015 : d’autres perspectives
La créativité est elle la seule réponse à la complexité ?
Y-a-t’il une manière 2.0 de dessiner un organigramme ?
Les salariés n’ont pas de temps à perdre à raconter leur travail
De quel réseau social une entreprise a-t-elle besoin ?
