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.
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.
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:
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.
/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.
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
Kommentar veröffentlichen