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

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

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.

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?

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.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.