Les projets et leurs prochaines premières actions

A tous,

Je lance ce sujet pour avoir votre avis sur un point de compréhension qui me pose problème dans la méthode GTD : une première prochaine action par projet.

Si j’ai bien compris la méthode, nous sommes censés n’inscrire qu’une prochaine action par projets ou bien créer des sous-projets et leur premières actions. Et faire confiance la méthode de planification naturelle qui nous amènera les prochaines actions en tant voulu. Aucun problème avec le perso.

Soit.
Au niveau pro, ça ne marche pas, surtout si on veut faire de la planification stratégique.

Je m’explique, si l’on veut faire de la charge capacité (prévoir les ressources homme/machine), et surtout savoir à l’avance où et comment affecter ces ressources, nous sommes obligés de dérouler les projets dans leur ensemble, c’est-à-dire dans mon jargon, faire un gantt précis et ultra détaillé qui permettra de dire : oui j’ai besoin de x ETP pour mener ce projet à bien. Ce qui permet in fine de prévoir des embauches et le budget pour le faire.

Si je ne mets qu’une action à chaque projet, je ne peux pas faire cet exercice là. Et je te dis pas la g… de mon ancien patron dans l’industrie pharmaceutique. Une partie de mon boulot était de planifier la fabrication de vaccins bactériens à horizon d’un, deux, trois jusqu’à cinq ans avec un horizon figé. L’horizon 5 à 10 ans équivalait à du LTIP (Long Term Industrial Planning). Cet exercice de dérouler les plannings et projets dans le détail permettait quelques années à l’avance, de décider de la construction d’un bâtiment de production et de l’embauche de personnel pour les prochaines campagnes de fabrication.

Mais avec la méthode telle que je l’ai comprise, si tu dis pas à ton patron combien ça va lui coûter et pourquoi, aïe. La planification stratégique en prend un sacré coup.
En gros cela voudrait dire : je sais où je veux aller, ma vision est claire mais je ne sais pas si je vais avoir besoin d’un paquebot ou d’une barque pour y aller.

Merci par avance pour vos réponses à ce sujet et si Romain peut nous donner son avis précieux, ce serait bien aimable.

Martine

Coucou @Margott :blush:

Oui tu as raison. j’ai eu le meme soucis avec certains projets.

Voici comment je vois les choses.

La prochaine action ne signifie pas, pour moi que tu doive te limiter à une seule action par projet. Si tel était le cas il n’y aurait pas grand chose. Dans beaucoup de « gros » projet on a des groupes de taches qui comportent chacunes une prochaine action

La Q c’est à quoi sert la prochaine action ? A une seule chose démarrer ton projet. Donc tu affecte en contexte que ce qui te permet de demarer ton projet et le plus précisément possible avec un verbe d’action pour que ton cerveau sache tout de suite quoi faire

ça n’empeche en rien de bosser globalement sur ton projet. Tu peux meme entierement le préparer. A noter que la planification naturelle de DA ne concerne que 5% des projets C’est simplement des projets qui sont tellement cruciaux qu’il faut faire le tour complet de la question. Heureusement 95 % des projets n’ont aucune PN mais seulement une prochaine action et SSI il sont actionnables et actifs.

Comme dans le BJ le projet n’est qu’un contenant. On retrouve cette notion de contenant partout chez DA. Dans les listes, les projets, les horizons… Partout.

Donc en bref si tu as un truc bien penible qui necessite un diagramme de gant tu le fais et tu mets en prochaine action dans ton projet l’action qui va te permettre de demarrer le projet. Ensuite dans OF tu met Cf diagramme de Gant que tu glisse en ref dans une note…

Et lorsque tu as fini tout ce que tu avais a faire tu met la prochaine NA
Hope that’s help/

Pour moi il y a deux choses différentes.

  1. C’est la facilité que procure un outil bien calé. C’est-à-dire à chaque projet une première action. Donc quand je me mets à bosser je regarde Todoist et selon le contexte j’ai toujours une action bien calibrée à faire. Ça permet d’être plus efficace au moment où je décide de travailler.

  2. Il y a ensuite la gestion de projet. Et là c’est plutôt avec la planification naturel que je m’organise. J’ai une vision totale d’un projet complexe qui nécessite plein de projets et de sous-projets avec chacun une action suivante. Personnellement j’utilise un logiciel de carte mentale pour avoir une vision d’ensemble sur ce projet complexe.

Est-ce que ça aide ?

Sujet intéressant,

Ma compréhension de la méthode GTD est qu’il faut a minima une prochaine action pour un projet. Par contre rien n’empêche d’avoir plusieurs prochaines actions.

Sur un même projet, j’ai souvent plusieurs prochaines actions avec parfois des contextes différents. Le point commun entre ces actions est qu’elles sont actionnables dès maintenant et ne dépendent pas de la réalisation d’une action précédente.
Quand je regarde un projet, j’ai accès directement aux actions que je peux actionner sans m’embarrasser de ce que je ne peux pas faire et je choisi l’action à réaliser en fonction de mon temps et énergie disponible.

Je suis intéressé par les avis des experts GTD sur le sujet.

3 J'aimes

Oui c’est ça sauf « qu’idealement » tu dois n’avoir en visuel qu’une seule prochaine action par projet. Mais je reconnais que ce n’est pas facile… Tout est dans le choix de cette 1ere action.

Petite remarque ici : il est tout à fait possible d’avoir plusieurs prochaines actions sur un même projet, c’est même assez courant, ventilées sur différentes listes de contexte. Je peux sur un même projet avoir à appeler Paul ou envoyer un e-mail à Sarah comme prochaines actions indépendantes, menables en parallèle, du coup j’aurai l’une sur la liste d’appels et l’autre dans mes e-mails à faire, je dois pouvoir voir l’une ou l’autre selon le contexte dans lequel je me trouve. Je peux même évidemment avoir 2 appels à passer comme prochaines actions independantes, les 2 apparaîtront sur ma liste d’appels. Il n’y a pas à choisir une seule prochaine action parmi plusieurs.

1 J'aime

Bonjour Romain,
Merci pour ta réponse mais mon problème n’est pas la. Ce n’est pas le choix de la première action qui me pose problème mais l’exhaustivité.
De la théorie GTD, je pensais avoir compris la chose suivante : il n’est pas nécessaire de mettre toutes les actions d’un projet dans notre système.
Même si tu dis qu’on peut avoir plusieurs actions dans un projet, de mon côté je parle de toutes les mettre. Faire l’exercice de dérouler un projet complet pour en déduire une capacité moyen et long terme.

que veux tu dire par exhaustivité ? Si c’'est la difficulté d’agir parceque tu as de nombreuses prochaines actions classees par contexte dans un projet, c’est souvent une question de definition de tes propres contextes. Cf ce que j’ecrirai bientot dans les contextes.

Non François
Je n’ai aucune difficulté à agir parce qu’il y a trop d’actions dans mon projet. Et travailler par contexte ne me dérange absolument pas.
C’est pas ça ma question.

C’est un point de théorie que je voudrais éclaircir : doit on mettre toutes les actions d’un projet dedans ?
A lire le livre de David Allen, j’ai cru comprendre que non.

Ne pas le faire ne me dérange pas en soi. Je peux en mettre une ou plusieurs dans mon projet peu importe. Mais ne pas tout mettre m’empêche de faire de la planification stratégique d’une part et de faire des offres de prix qui prennent en compte tous les besoins en ressources d’un projet.
Dans son livre David Allen parle de 5% des projets qui sont à dérouler entièrement. Je pense que mon topic parle de ces cas là.

Si chaque branche de ton projet ne possède qu’une action suivante alors comment tu fais pour évaluer la charge globale de ton projet et donc en déduire le besoin en nombre de personnes, machines ou fournisseur pour mener à bien ce projet ?
Moi ça me pose un vrai problème le truc d’une seule prochaine action par projets. Cela ne permet pas de faire de la planification stratégique.
Et c’est une limite de GTD que j’avais immédiatement comprise.
Avec des capacités et des ressources finies, on ne peut pas raisonner à l’infini.

Ah OKKKKEY :rofl:
Tres bonne question. Il faut demander @Romain

Je crois qu’il faut distinguer 2 types de projets (en tout cas moi, c’est comme ça que j’ai géré le sujet… :wink: ) Pour moi l’idee principale c’est que le projet est un contenant. Un entrepôt à idee, taches, references sous reserve de ce que j’explique ci apres…

  1. Les projets « de base » qui n’ont pas besoin d’une planification naturelle (95%)
    La je met tout tout tout dans Omnifocus. Mes actions sont classées par contextes et j’en ai 2 particuliers. #Smb pour mes action « futures et eventuelles » et #Ref. = Reference pour mes reference exemple j’aime noter les entretien telephoniques avec mes clients (en attendant mieux comme systeme) ou les references dans mon bujo ou meme des numeros de telephones de personnes que je ne veux pas dans ma base contact.

  2. Les projets plus complexe qui ont besoin d’une PN
    la on joue sur du compliqué svt diagramme de Gantt, multiple intervenants etc…
    Ici je me sert d’OF comme d’un centralisateur qui renvoi a des references
    Exemple la tache « projet XX / Diagramme de gantt » a un lien cree dans OF > ‹ CTRL fichier › (attention a ne pas glisser le fichier en note il rentrerait dans la base :rage: ) Une autre tache dira Projet XXX / ET (= entretien telephonique) Mr DUPONT renverra sur un fichier qui souvent est un word mais parfois est en google doc. lorsque je veux le partager par exemple

Omnifocus gere tout ça tres bien.

Est ce que cela répond à ta question ?

Carrément !
J’ai eu du mal à me faire comprendre je crois.
Merci beaucoup François. :slight_smile::wink::star_struck:

1 J'aime

@Margott Je n’avais pas répondu parce que @francois avait bien répondu :slight_smile: Tu peux tout à fait gérer l’intégralité de ton projet comme tu as l’habitude de le faire, GTD c’est de la gestion (de l’attention, in fine, mais ça commence par) des tâches, pas de la gestion de projet collectif. Beaucoup de projets d’envergure nécessitent la définition d’un chemin critique, de l’affectation de ressources et d’être gérés avec des Gantt ou en mode agile, GTD ne va pas contre ça.

La seule différence de GTD, c’est que chacun n’ira reporter que les prochaines actions dans ses listes persos (parce que ce sont les seules que chacun peut faire au moment d’agir), toutes les autres resteront dans le projet en attendant leur tour.

Je connais aussi des sociétés qui gèrent leurs projets sur des Kanban, où sont écrits les jalons ou les « tâches » à faire (ici, tâche à le sens commun, qui n’est pas celui de GTD, et qui correspond souvent à une série d’actions menant à un mini-résultat) ; chaque personne de l’équipe prend en charge une de ces tâches (déplacement sur le kanban) et ne met dans ses listes que la prochaine action correspondante. Une fois le mini-résultat atteint, déplacement de la tâche terminée ou bloquée dans la colonne qui va bien, et zou.

Donc, en clair, tu fais ton plan d’action avec tout ce que tu as besoin de planifier à l’avance (jalons, échéances, chemin critique, ressources, budget, etc. —la MPN permet souvent de préparer ça avec le moins d’efforts possibles), et quand vient le moment d’agir, tu pars de tes prochaines actions (parce qu’il n’y a pas moyen de partir d’autre part, en fait).

J’ajoute encore, pour finir, qu’en termes pratiques, tu peux soit :

  • choisir de ne mettre que les prochaines actions dans ton logiciel et laisser toutes les autres dans ton projet (et aller les chercher à mesure qu’elles deviennent de prochaines actions à leur tour),
  • choisir de toutes les mettre dans ton logiciel, mais à ce moment-là prendre bien garde à n’affecter de contextes qu’aux prochaines actions (comme ça, les autres tâches restant sans contexte n’apparaîtront pas dans tes listes), et affecter tes contextes pour toute action à mesure qu’elle devient à son tour la prochaine.

D’expérience, la première solution est la plus viable, surtout sur des projets complexes impliquant de nombreuses personnes, notamment parce qu’il est peu pratique de dérouler tout un projet en prochaines actions (en général, on passe d’un jalon à l’autre ou d’une « tâche » à l’autre, on est plus « macro »), et aussi parce qu’un projet se déroule rarement comme prévu, et que s’il faut changer de cap à un moment, toute la belle décomposition de prochaines actions passe à la baille —et dans GTD, ce qui est sûr, c’est qu’on n’aime pas bosser pour rien :slight_smile:

4 J'aimes