Direkt zum Hauptbereich

Team players document their stuff

You’re looking for some information, but the documentation is missing, hasn’t been updated or perhaps never existed. You ask a teammate, who points you to two contradictory versions. Which can you trust? She can’t recall either. Sloppy, incomplete, obsolete documentation is frustrating and a productivity killer. Above all, it’s a team problem.

Before we dig into the team aspects of good documentation, let’s look at the scope. First, a definition: documentation is any record for the purpose of capturing needed information and data about some object, either for the future (memory) or for others (communication). Second, we document in lots of places, ranging from manuals, handbooks or work instructions to tool-based systems like CRM systems, CMDBs/1/, intranets or various databases and, of course we have paper notes, Kanban boards, e-mails – you name it. Third, in a work context, documentation is primarily an efficiency issue: we document to avoid having to recreate the knowledge. Finally, documentation has one vital requirement: to be valid, it must be authoritative. We need to know that it is accurate and current.

Examined from a Lean perspective, poor documentation causes waste. It leads to errors, many of which first become apparent far downstream in the process. For example, the customer notes that the invoice is wrong. Tracing the error back through the chain, we discover that the customer’s order was entered wrongly into the database. As a result, products or entire systems were built to the wrong specification. The correction effort can be as much as the initial effort, including spillover into rework for all subsequent processes./2/ Poor documentation is even waste in itself.  If the documentation isn’t reliable, then the effort to create it is waste, as it adds no value.

It’s a team issue

If you work entirely on your own, your system is your own. It need only suit you, and if your documentation isn’t good, you only have yourself to blame. By contrast, teams need documentation to hold and pass the necessary knowledge and data together. We rely on each other not only to perform our tasks, but also to capture and maintain the knowledge. If we want a team to be more than the sum of its parts, there can’t be negative numbers (errors) added to the equation.

I suspect that poor documentation is a leading cause of errors and rework. I have personally experienced examples like the one above. All of the persons involved were competent, well-meaning, team-minded persons. But, we as a team lacked good documentation practices and policies, leading to horrendous inefficiencies in our work.

What to do?

So, what can a team do to improve the situation?

1) Recognize that being a team player means documenting your work so that others can rely on it.

2) Insist on your colleagues documenting their stuff.

3) Obey rules of good data hygiene:

  • Hold each piece of information in just one place. That way, there can be no contradictions, and it means less maintenance effort.
  • Use and insist on others using the autoritative source of information.
  • Only document what is really needed. Agile teams seek a minimum of documentation or self-documenting solutions, both to avoid excessive effort and enable easy maintenance./3/
  • Integrate documentation into the production, creation or change process. It can even be effective to document first and create second. In IT systems, it is possible to automate the production or change activities based on the content of the CMDB. 
  • Delete or archive old versions immediately.
  • Recognize that an error is worse than missing information. (If something is missing,  we keep looking for the answer. If the information is wrong, we assume it’s correct and create further errors.)
  • Set up auditing processes and tools to find and correct errors efficiently.

4) Agree all of the above with the team. It is a myth that Sharepoint or other documentation systems will solve documentation problems on their own. It’s a garbage in–garbage out issue that technology cannot solve. No amount of tagging will resolve the fact that your team has never agreed the documentation structure and rules.

With just a bit of discipline and team smarts, this major source of frustration is actually easy to solve.

How much time do you lose each week due to poor documetation (either in searching for the real answer or in rework or other inefficiencies)? I am keen to hear your experiences.


Notes

/1/ For the non-IT readers, a CMDB is a “configuration management database”, or more properly it is the database part of a configuration management system (CMS). Arising first with the mass-production systems in early part of the twentieth century, a CMS serves to record all necessary information of all the parts in a system so that they can be tracked and verified. In the IT, the CMS/CMDB is thus a key tool for holding all information about a the IT systems for the sake of resolving errors, planning changes etc.

/2/ Robert Falkowitz has captured interesting ideas about Lean configuration management in an article called “Lean Configuration Management: a conundrum” [https://www.3cs.ch/lean-configuration-management/]. His observations are useful, but he focusses mainly on issues of effeciency and delays in maintaining the CMDB, thus completely overlooking error rates as a source of waste. Most companies struggle with the quality of the information in their CMDBs, with resulting errors and massive rework to correct the errors. How much time they spend on the CMDB is secondary.

/3/ Many companies rely on discovery solutions to avoid the whole issue. They fill their CMDBs automatically from the existing infrastructure to avoid the effort of (and having to rely upon) manual documentation by human beings. It may save effort, but it doesn’t solve the problem. We will always need a record of the intended, or target state that is distinct from the current state of the infrastructure. Often the target state will be driven by a customer order (or perhaps an internal standard). This target state must be entered somewhere to serve as a reference for the current state. Now, it may also be possible to capture the target state automatically. But, that doesn't obviate the need for a distinction between target and current states. The truly valuable information arises in a comparison of two.

Kommentare

Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

Psychologische Sicherheit: Das Geheimrezept hoch performanter Teams

  Psychologische Sicherheit ist ein Konzept, das hoch performante Teams auszeichnet.    In Zeiten zunehmender Ausfälle aufgrund psychischer Belastungen am Arbeitsplatz findet das Thema immer mehr Beachtung in der Gesellschaft und Wirtschaft. Psychologische Sicherheit beschreibt einen Zustand, in dem Teammitglieder in einem als persönlich sicher empfundenen Umfeld, produktive Ergebnisse erzielen. Verantwortung, Vertrauen und Verletzlichkeit bilden das Fundament gemeinsamer Zusammenarbeit.   Indikatoren für eine geringe psychologische Sicherheit im Team: ·         der Status quo wird nicht offen hinterfragt ·         Ideen oder Fehler werden nicht offen kommuniziert ·         Teammitglieder scheinen mehr Energie darauf zu verwenden, "das Gesicht zu wahren" ·         Meetings ufern regelmäßig aus - Diskussionen statt Ergebnisse und Entscheidungen ·         nach einem Meeting fragen sich Kollegen regelmäßig, wieso sie überhaupt an dem Termin teilgenommen haben ·  

Wie liest man sich in Scrum und Agilität ein?

Nehmen wir an, Sie hätten keine Ahnung von Scrum und Agilität. Aber Sie spüren bei Ihren (Beratungs-) Kunden immer wieder, dass sie diese Themen bewegen. Wer sind die Player, welche Bücher sind wichtig? In diesem Artikel versuche ich einen Überblick zu geben.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.