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?

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.

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.

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.

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.

Tooling #5: Die gute alte Systemtheorie

Gelegentlich fragen mich Menschen nach den wichtigsten Tools und Herangehensweisen für meine Arbeit. Einige davon habe ich hier im Blog bereits vorgestellt (und zwar  hier ). Heute möchte ich über ein weiteres, vielleicht sogar DAS entscheidende Basiswerkzeug sprechen: Die gute alte Systemtheorie.

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.

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

Ich bin ganz oben (mit Kanban und Outlook)

Mit einem Kommentar zu einem lesenswerten Artikel von Thomas Mauch /1/ habe ich es an die Spitze der Trefferliste bei Google geschafft. Suchen Sie mal nach „Kanban Outlook“. Kanban ist eine alte Idee, aber immer noch der Renner unter den Produktivitätswerkzeugen. (There is an English version of this post.)

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.