Direkt zum Hauptbereich

A simple guide to keeping a journal in business

Professional work is documented and reproducible. The basis for good documentation is writing things down personally. There are many instructions online for different areas of application. I was looking for an integrated approach.

Why is it important that we write things down?

I still remember the first few days while studying when I was new in a lab. The professor had agreed to let me write a term paper in his department. On the second day, he came to me and asked me to start writing.

I asked back: "What should I write down? I haven't even started the work yet."

He replied: "Write down what you plan to do! Write down how you want to proceed! Write down what literature there is. What are the important terms?"

Wow. He was right. These were all things that I could already write down. I learned from him how to write. Writing helps me think. In this blog, for example, I write down my knowledge and insights that I will need later. If I write down important things, I save a lot of time later because I don't have to do the research again.

What should you write down in business?

Over time, I have learned that the following information helps me:

  • Journal: There are days when I write down a lot. It's information about my cases and projects. Maybe also tasks that I want to complete. There is a journal section in my notes for this. But these notes shouldn't live long. Watts Humphrey recommended keeping an engineering journal.
  • Project notes: I have a note for (almost) every task or project. These are basic information about a process, e.g. contact persons or links to systems. But also next steps and results. David Allen recommends keeping a projects list.
  • Knowledge notes: Then I need an area in which I store my knowledge for the long term. Recently, I have done a lot of research into the history of the ideas behind Scrum or requirements management. There are lots of little notes about people, institutions or events. Long-term knowledge, however, also includes information on how I edit a video with ffmpeg. Sönke Ahrens recommends a zettelkasten for this.

Each category has to be organized differently so that I can find something again. 

Are there any special principles or rules that make note-taking and note management easier?

I have had a few problems in the past with the many different types of notes:

  • I forgot to write down something important. (Or I wrote it down but forgot where I put it).
  • Notes become outdated. I lost track of what was still current and what was not.
  • Notes, tasks and information were in many different places.

I therefore thought about or copied a few principles:

  • There is only one place where the notes are. I used to have notes in different places. This led to long search times.
  • Temporary notes are separated from permanent notes. Separate the dynamic from the static notes.
  • Write down the sources where you found something.
  • Revise notes regularly. Create overviews regularly.
If I only have one program for notes, what could a structure look like?

Structure for notes

I have three places for my knowledge:
  • my program for notes (e.g. Obsidian),
  • a literature database for all books, articles or other sources (e.g. Zotero) and
  • my file storage, where all files and emails are located.
I have the following structure in my note program:
  • Journal: a note for each day. The diary is tidied up regularly.
  • Project notes: a note for each process or project. When I group the projects or processes into folders, I use the same logic as for my file storage.
  • Knowledge notes: there are many small notes here. There is a very rough list of topics by which I sort my notes. This list follows a different logic than that of the file storage. I also use this list of topics when managing my literature.

 

Fig. 1: A structure for notes

Are there special routines?

Yes. I have gotten into the habit of a few things:

  • Every day a note is created (automatically) for the day.
  • Every morning I go through the note from the previous day. I transfer the knowledge and some tasks to the process or knowledge notes. I transfer the tasks that I want to do today to today's note.
  • A note is created for each new project.
  • When a project (or case) is completed, the note is archived. I either move it to the archive folder in my note program or I save the file for the project in my file storage. This should definitely make it disappear from the list of active processes.
  • I note down references to books, videos, blog articles, etc. in my literature database on the relevant topic.
  • Knowledge notes are filed in the relevant topic. Each knowledge note contains a link to the index of the topic.

Anyone who wants to delve deeper into this topic will find useful knowledge in these books:

 

Kommentare

Beliebte Posts aus diesem Blog

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Erfahrung mit Vibe-Coding - und warum das keine Teamprobleme löst

Die KI-Werkzeuge zum Erstellen von Werkzeugen für die tägliche Arbeit werden immer besser. Die selbstgestrickten Tools erleichtern die eigene Arbeit. Aber für den Einsatz im Team fehlt noch etwas.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen. 

Wenn Leisten Leistung kostet

Immer. Immer "on". Immer mehr. Immer schneller. Und natürlich: Immer besser. Das ist die Welt, in der wir heute leben. Eine Welt der Dauerleistung. Und die hat ihren Preis: Wir werden schwächer. Sofern wir nicht die Grundlagen guten (Selbst-)Managements beherzigen und Pausen machen. Also zur richten Zeit das wirklich Wichtige tun.

A shared file storage is not a library

In over 90% of cases where we advise organizations on filing systems, we find that they are organized by topic. This system quickly leads to chaos because outdated documents are not disposed of quickly enough. So why does everyone think to structure their filing system by topic? I believe we have the wrong idea.

From False Starts to Precision Landing: The Evolution of Requirements Management

Requirements management originated in U.S. rocket programs between 1945 and 1970. A small management trick contributed to the success of the Apollo program.

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Wie läuft ein Projekt zum Entwickeln von Szenarien ab?

Seit 2016 beschäftigen Edgar und ich uns intensiv mit der Szenariotechnik. Szenarien sind ein wirkungsvolles Werkzeug, um Projekte oder ganze Geschäftsmodelle auf ihre Zukunftstauglichkeit zu testen.