GTD, Teil 2: Klassische Kontexte und ihre Probleme

Besonders für Freiberufler ergeben die klassischen Kontexte nach David Allens »Getting Things Done« oft nur wenig Sinn. Wo die konkreten Probleme liegen diskutieren wir in diesem zweiten Teil der GTD-Reihe.

Wie letzte Woche besprochen ist der Einsatz von Kontexten ganz generell für viele Menschen schwierig geworden. Kontexte scheinen von der modernen Realität überrollt worden zu sein. Dabei ist das Prinzip auch heute noch sinnvoll – der Kontext ist aus gutem Grund die wichtigste der vier Säulen der »Getting Things Done«-Methode. Das System geht davon aus, dass man jede einzelne Aufgabe nach vier Kriterien definieren bzw. auswählen kann:

  1. Kontext
  2. Nötiger Zeitaufwand
  3. Nötiges Energieniveau
  4. Priorität

Nicht immer muss man für eine Aufgabe alle vier Kriterien festlegen, aber: Zu jeder Aufgabe gehört immer ein Kontext. Nicht unbedingt der erwartete Zeitaufwand, das benötigte Energieniveau (»wie geistig fit muss ich sein, um diese Aufgabe zu erledigen?«) oder eine Priorität. Aber Kontext? Ein Muss.

Der einsame kanonische Kontext

David Allen definiert den Kontext als das eine Ding, das unverzichtbar ist, um eine Aufgabe abhaken zu können. Sowohl 2001 als auch in der überarbeiten Neuauflage seines Buches von 2015 zeigt er sich davon überzeugt, dass es tatsächlich immer ein Ding sein wird – wenn man das Gefühl hat, dass eine Aufgabe in mehrere Kontexte passen könnte, hat man entweder seine Kontexte schlecht gewählt oder aber die Aufgabe noch nicht gründlich genug in Einzelschritte herunter gebrochen.

Kanonisch unterscheidet GTD zwischen ortsgebundenen Kontexten, Ressourcen-Kontexten und Meta-Kontexten. Die meisten GTD-Nutzer verwenden in ihrem persönlichen System eine Mischung aus diesen Kontext-Typen, was nicht selten zu Problemen führt.

Ortsbezogene Kontexte legen fest, wo man sich aufhalten muss, um eine Aufgabe zu erledigen. Wenn die Aufgabe »Katzenklo leeren« ansteht, hat es wenig Sinn, wenn man im schicken Coworking-Space daran erinnert wird. Verschiedene digitale Aufgabenverwaltungen wie z.B. OmniFocus können Kontexte mit GPS kombinieren. Betritt man dann den Baumarkt, poppt die Aufgabe »Vorschlaghammer kaufen!« auf dem Handy auf. Ist man aber in der Migros, ist die Aufgabe nicht sichtbar – dafür erscheint vielleicht »OMG Tampons! Wir brauchen Tampons!!!«.

Das Problem: Wir arbeiten immer dezentraler. Ob man ein Projekt im Heimbüro, in einem der drölfzillionen Coworking-Spaces oder im ÖV fertigstellt ist egal, und mit Online-Shopping kann man sich zur Not Tampons (und Vorschlaghammer) auch frei Haus liefern lassen.

Ein Ressourcen-Kontext versucht, das eine unverzichtbare Werkzeug oder eben: die eine unverzichtbare Ressource festzulegen. Wenn man Daten aus dem abgeriegelten Kunden-Intranet benötigt, dann braucht man eben Intranet-Zugang. Bei einer Aufgabe wie »Spesenabrechnung mit Kunde besprechen« ist es vielleicht wurst, ob man das telefonisch, per Mail oder mit Rauchzeichen erledigt, aber man benötigt halt dazu den Jochen-aus-der-Buchhaltung.

Das Problem: Je nach Beruf hat man ständig Zugang zu den benötigten Ressourcen. Ein Telefon haben die meisten Menschen unserer Hemisphäre eh 24/7 bei sich. Und ob der Jochen überhaupt noch für Spesen zuständig ist? Das kann sich schnell ändern, und als Freelancer hat man nicht unbedingt den vollen Einblick in die Firmenstruktur des Kunden.

Meta-Kontexte dienen hauptsächlich dazu, die tagesaktuelle Aufgabenliste sauber zu halten. Wartet man z.B. auf Feedback zu einer Projektmappe, dann hilft es wenig, wenn das in der Liste geführt ist – es ist keine aktive Aufgabe, die ich anpacken kann. Der Klient muss sich melden. Und dass ich mir vorgenommen habe, vielleicht nächsten Sommer eine Baumhütte zu basteln oder drei Monate in Ísland zu leben ist zwar schön, aber daran kann ich tagesaktuell nicht wirklich arbeiten.

Das Problem: Meta-Kontexte werden schnell zu ungeordneten Sammeltöpfen. Statt dass man sich bei Aufgaben fragt, zu welchem Projekt und in welchen Kontext sie gehören, wirft man sie in die Meta-Listen. Ich kann mich spontan nicht für einen passenden Kontext für »Klempner anrufen« entscheiden? Ab nach @Agenda damit! Ich sollte mal die Sache mit dem Fitnesscenter angehen? Och, @Someday vielleicht …

Vermischung als Hauptproblem

Neben der Frage, ob die klassischen, kanonischen Kontext-Ansätze in der heutigen Zeit überhaupt noch Sinn ergeben, stellt die Wahl des »richtigen« Kontexts das Hauptproblem dar. Besonders schwierig wird es, wenn man Kontext-Typen kombiniert. Ist es für eine Aufgabe relevanter, dass sie im @Büro erledigt wird, oder mit @Kundendatenbank? Gehört die Vorbereitung für eine Präsentation zu @Agenda:Projektleiter oder eher in die Kategorie @Powerpoint? Viele wünschen sich entsprechend die Möglichkeit, mehrere Kontexte vergeben zu können – was beim klassischen Papier-und-Ordner-GTD extrem aufwendig wird und bei digitalen Werkzeugen wie OmniFocus (noch?) nicht vorgesehen ist.

Ein Weg aus diesem Dilemma ist der bereits letztes Mal geforderte kreativere Umgang mit Kontexten. Welche Möglichkeiten es hierfür gibt, besprechen wir im nächsten Beitrag.

2 Gedanken zu „GTD, Teil 2: Klassische Kontexte und ihre Probleme“

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.