Wo David Allen falsch liegt

In seinem Bestseller  “Wie ich die Dinge geregelt kriege: Selbstmanagement für den Alltag” beschreibt David Allen eine System zur Selbstorganisation welches weltweit unter dem Namen GTD (vom englischen Originaltitel “Getting Things Done”) populär geworden ist. Ein wichtiger Bestandteil seines Konzeptes sind die sogenannten Kontexte. Vorhaben werden in ausführbare Aufgaben aufgeteilt und nach Möglichkeit wird ihnen ein Kontext zugeordnet in dem diese Aufgabe ausgeführt wird.

Kontexte sind Umgebungen oder Situation in denen man bestimmte Arten von Aufgaben ausführt. Ein Kontext kann z.B. Telefon sein. Diesem Kontext werden alle Aufgaben zugeordnet die man erledigen kann wenn man ein Telefon benutzt. Ein weiterer Kontext könnte z.B. “zu Hause” heissen und Aufgaben beinhalten die man nur zu Hause erledigen kann.

Die Idee dahinter (und hinter dem ganzen GTD System) ist es, die “Denkarbeit” in der Planungsphase zu erledigen und größere Vorhaben in möglichst kleine, konkret ausführbare Aufgaben zu unterteilen. Diese Aufgaben sollen dann ohne größeres Nachdenken zu erledigen sein. Steht mir z.B. zwischen zwei Terminen nur ein Telefon zur Verfügung könnte ich die Zeit nutzen die Aufgaben aus dem Kontext “Telefon” abzuarbeiten. Das sollte nach David Allen ruck zuck gehen, da die Denkarbeit ja schon in der Planungsphase erledigt wurde und die Aufgabe auf meiner GTD-Liste konkret ausführbar ist.

GTD contexts

 

Und genau hier sehe ich ein Problem. Doch bevor ich erkläre warum, müssen einige Begriffe gerade gezogen werden. In der Einleitung sprach ich von “Kontext” im Sinne von GTD. Im weiteren Verlauf werde ich diesen GTD Kontext als “@context” bezeichnen. Der @context bezeichnet wie gesagt eine bestimmte Umgebung, Situation oder Hilfsmittel in dem Aufgaben erledigt werden können. Darüber hinaus werde ich das deutsche Wort “Kontext” im Sinne des Projektzusammenhangs verwenden. Eine Aufgabe eines Projektes lässt sich leichter erledigen, wenn man den Kontext (das Ziel des Projektes, die anderen Aufgaben des Projektes etc.) kennt.

Nach David Allens GTD soll man versuchen Aufgaben im Rahmen eines @context zu erledigen. Das heisst, wenn ich ein Telefon zur Verfügung habe, dann erledige ich alle Aufgaben welche ich zuvor in den @context “Telefon” eingeordnet habe. Bin ich zu Hause, dann arbeite ich alle Aufgaben des @context “zu Hause” ab usw. Diese Aufgaben gehören i.d.R. zu verschiedenen Projekten. Sie müssen alle so einfach formuliert und vorbereitet sein, dass sie sich ohne den Projektkontext erledigen lassen. Warum ist diese Kontextlosigkeit hier so wichtig? Weil wir sonst bei der Abarbeitung in eine klassische Multitasking- bzw. Kontextwechsel-Situation kommen würden. Die Aufgabe muss so einfach formuliert sein, dass ich sie ohne weiteres nachdenken (die Aufgabe in den Projektkontext setzen) erledigen kann. Ist sie das nicht, so muss ich während der Abarbeitung meiner Aufgabenliste ständig Zeit mit dem context switching zwischen den Projekten verbringen. Je mehr Aufgaben aus verschiedenen Projekten ich in einem @context habe, desto öfter müsste ich bei schlechter Planung im Kopf den Kontext wechseln. Dies ist anstrengend und ineffektiv.

Das Credo wäre also, während der Planung die Aufgaben möglichst so klein zu machen, das sie Kontext-agnostisch sind. Das heisst, sie lassen sich erledigen, ohne den Projektkontext zu kennen. Und hier setzt meine Kritik an. Solch eine Planung bzw. sehr fein granulare Aufteilung von Vorhaben ist sicherlich möglich. Man muss halt in die Planungsphase genug Gehirnschmal investieren und die Aufgaben entsprechend simple halten.

In der Praxis heisst dies jedoch für mich, dass ich in die Planung zu viel Zeit investiere. Die Aufgaben so simpel zu formulieren, dass sie ohne Wissen um den Kontext ausgeführt werden können ist sehr aufwendig. Bei meinen Planungssessions habe ich hier gerne mal mehr Zeit für die Planung als für die Erledigung der eigentlichen Aufgabe verbracht.

In irgendeinem Blog hatte ich mal einen Tipp für die Planung gelesen: Man sollte die Aufgaben so formulieren als würde man die Erledigung an jemanden delegieren der von dem eigentlichen Projekt nichts weiss. Dies ist eine ganz gute Analogie finde ich. Sie verdeutlich genau diese Kontext-Agnostik die bei der Ausführung angewandt werden sollte.

Speziell für @contexte im Arbeitsumfeld wie z.B. “@eMail” oder “@Office” ist aus meiner Sicht eine Kontext-agnostische Planung überhaupt nicht effizient. Vorhaben müssten in sehr viele kleine Aufgaben unterteilt werden die dann in der nächsten Planungssession wieder wie ein Puzzle zusammengesetzt werden müssen.

Aus meiner Sicht ist deshalb dieser Teil des Systems GTD mit sehr viel Vorsicht zu genießen. Ich finde es effizienter mich auf ein Projekt zu konzentrieren statt auf einen Kontext. Hierbei muss die Planung nicht ganz so kleinteilig sein da sich durch die Fokussierung auf ein Projekt im Kopf ein Kontext bildet der bestimmte Informationen über das Projekt sozusagen als Umgebungsvariablen enthält (Computerfreaks wissen hier schon was ich meine) ohne das man diese explizit niedergeschrieben haben muss. Das Aufwendige Kontextwechseln entfällt hierbei.

Autor: falko

a *nix nerd