L'ouvrage de Rafe Esquith, "Il n'y a pas de raccourcis", est le livre le plus inspirant que j'aie lu à propos de l'enseignement - et je suis intimement convaincu d'être invité à jouer un rôle d'enseignant à maintes occasions, en tant que responsable de projet.

J'aime la façon d'écrire de Rafe Esquith. Des anecdotes, des dialogues, un style lisible et une critique sans pudibonderie. Ca réveille. Et, tout particulièrement, Rafe Esquith nous invite à relire avec lui son expérience sans langue de bois, à tirer avec lui les leçons de ses échecs même les plus subtils, dont les causes lui sont plus intérieures. Simplicité et humilité. C'est énergisant. Merci, Monsieur Esquith.

The most inspiring book I've read about teaching - and I'm convinced that, as a project manager, I'm bound to act as a teacher in some occasions. See also that review I find relevant: 

http://www.enotes.com/topics/there-no-shortcuts

I love the way you write, M. Esquith. Anecdotes, dialogues, readable style and criticism without prudishness. You wake me up. And, especially, you invite us to read over your shoulder your experiments without jargon, to harvest the lessons of your failures whose causes sometimes are innermost. Simplicity and humility. Energizing. Thank you, M. Esquith.

Managing collaboration with professionals scattered all around, this is what detailed schedules are meant to help with. Heavy but powerful tool. Drawback: schedule updates are energy-consuming. Cost / benefit ?

In some cases—which ones? depending on what settings?—detailed schedules can hinder progress. The project manager glued to their computer may abandon the field. Self-deprived of the means of their proactivity, they come to consider actuals as mere variances with planned values. Their main concern has become: keep documents up to date—this is achievable, whereas putting the project back on tracks may no longer. The vicious circle is not far away.

In these cases—let me repeat: which ones? depending on what settings?—, specifically, I’d like to propose we plan up to the decomposition of work (I mean, deliverable-oriented) and refrain from defining activities beyond the coming week / two weeks. Finally, each employee has this simple question in mind: what is my next thing to do? Not quite "where do I fit in the sequence of all activities?".

Advantages to stick to the deliverable-oriented structured breakdown of the work? I’m leaving to the employee care to discern the activities to achieve the deliverable they are responsible for and I trust them to organize their collaborative network. I’m focusing my attention on concrete achievements, delivered or to be delivered, which helps measure the project progress objectively. I’m investing my energy on deliverables which I am to understand, not on  activities about which I am technically incompetent. I’m stopping the breakdown of the work at the detail relevant to me, I’m delegating to employees whose expertise and autonomy I respect.

Benefit to stick to the structured breakdown of work? I may invest time saved on schedule updates back to clearing away the obstacles in the way of employees, they will acknowledge their responsibility, the project progresses, people are happy.

The underlying hypothesis / beliefs are : the project team are committed, people are skilled, people are eager to work (theory « X »). Less time screwded at the computer, everyone has more energy to devote to people and deliverables. The virtuous circle rolls on.

Next step: let’s revise our structured decomposition of work, as it is today: how could we make it more suitable to delegation to autonomous people? Why not ask our peers ?

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 ?