The database server is down. Work is stopped across the state. My chest is tight, as this server is my responsibility to maintain. Even though the server room is heavily air conditioned, I feel beads of perspiration forming on my forehead. My fingers flit across the keyboard, tapping in diagnostic commands. I didn’t set this server up, but inherited it with scant supporting documentation from an already absent predecessor when I started the job, so troubleshooting without knowing the precise system configuration is tricky. As the command output scrolls by on the monitor, some intuitive calculus in the back of my mind updates the probability that I’ll be able to get the database back on-line versus have to rebuild it from backups. Thankfully, I know I have the safety net of that latter, though unattractively laborious, alternative. One of my first projects coming into this job was to set up consolidated backups. As I set the server to perform a lengthy self-check, I decide to review the backup documentation that I wrote to see when the last backup should have run, what media it’s on, and how the restore actually works. Even though it’s only been a couple of months since I set up the new backup system, that’s not the kind of detail I can keep in my head, so I knew enough to write it down for just this type of occasion.
Not that I had always known. That knowledge came from hard won experience trying to troubleshoot problems—or even make seemingly simple changes—on systems that I myself had set up and then, even only a month or two later, had to struggle to recall how they worked and what to do when working on them. After a few of these harrowing and frustrating experiences (thankfully without a statewide network of employees waiting on my missteps), I realized there had to be a better way. If, as the person who actually set up the system, I didn’t know what to do, what would happen if I weren’t available and someone else had to step in? I decided then that the gift I would give to any successor in my position (including and especially my future self!) was concise configuration and procedural documentation.
I look back at the server diagnostic progress indicator and see it’s still crawling along. Probabilities of a quick fix dwindling. From my notes, the restore process looks straight-forward but time-consuming. Bad news for everyone across the state waiting for access. I start to compose an outage status update e-mail message to those users. The server beeps as the self-diagnostic finishes. Data corruption. Probablitiy zero. I finish the e-mail and press Send. Time to start checking items off my restore procedure.
Since those days as a systems administrator, I’ve carried this and similar lessons of the value of documentation with me. As I moved into management, I learned that there are many more good reasons to document work procedures. I made it a point to lead my teams with that in mind, co-creating written standard operating procedures (SOPs) for much of our department’s routine work. I would regularly annoy my staff with my proverb to proceduralization: “If it’s not documented, it’s not done.” This gentle chiding was sometimes necessary because very few people like writing documentation, even if they recognize its value. Not even me. It feels like extra work. And if you start to think about everything you do at work that could be documented, it feels overwhelming. Who has the time?
But properly done, effective documentation can actually save you time: Time wasted in inefficient, inconsistent work that could be avoided with a well-thought-out standard procedure, time lost in rework and apologies in making up for mistakes that could have been avoided by following a checklist, as well as time saved in not having to look everything up from disparate sources or discover through trial-and-error a workable path in a one-off situation like my server recovery.
The key to success is leveraging your documentation effort through structured prioritization. If you start by identifying the “low hanging fruit” and documenting those procedures which will remove bottlenecks, increase efficiency, or eliminate avoidable errors, you can actually increase productivity, giving you back time and allowing you to build momentum on improving your organization’s outcomes.
Start reclaiming your time now by following this 5 step process:
1. Determine Documentation Drivers
What’s motivating your desire to document? What undesirable outcome do you fear will occur (or is already occurring!) in the absence of written procedures? What big benefit are you looking for by documenting workflow?
Reasons for documenting work procedures may include:
|Error-Proofing||Reducing avoidable errors / increasing quality by implementing SOPs as a mistake-proofing technique.|
|Are mistakes costing you customer satisfaction and creating the waste of rework? The quality management lessons of Deming and Juran teach us that variation in process leads to variability in output. Even routine procedures can benefit from documentation, especially quick-reference checklists, to ensure correct completion the first time.|
|Efficiency||Increasing productivity by standardizing work through SOPs.|
|Are you wasting time (read: salary money) by completing work less efficiently than possible? Having a standard work process is the foundation for continuous improvement. This is a core principle of Lean manufacturing, and is no less applicable to knowledge and service work. Peter Drucker has argued that the greatest potential for sustaining competitive advantage in developed countries lies in translating the gains in manufacturing productivity the 20th century saw to increase the productivity of knowledge workers in the 21st century. That competitive advantage starts in individual organizations like yours.|
|Delegation||Off-loading/out-sourcing processes performed by high value employees (like you!).|
|Do you or your most highly compensated employees perform routine work simply because you or they are the only ones who know how to do it (or do it “right”)? Is there important work not getting done because a key resource is too busy with routine activities? Are there bottlenecks in workflow keeping your company from meeting its mission? Documenting a procedure makes it easier to delegate, freeing up time for higher-value work. When applied to time-consuming activities, such strategic delegation can create enormous leverage in an organization through more productive use of human resources.|
|Training||Orienting new employees on workflow.|
|Are you spending too much time orienting new employees? Effective documentation can dramatically reduce time involved in training new employees to achieve task proficiency. This is especially important if your organization is growing quickly or experiences significant turn-over.|
|Business Continuity||Mitigating risk by documenting critical procedures that only one person knows how to do.|
|What would happen if you or one of your employees got hit by the proverbial bus? Are there things you or they do that no one else is aware of, much less knows how to do? Even barring catastrophe, people get sick, get new jobs, and eventually, retire. Documenting key procedures provides needed insurance against the loss of tacit knowledge.|
|Compliance||Ensuring conformance with an external quality or auditing standard.|
|Do you operate in a regulated industry? Does your functional specialty require compliance with specific domain rules or regulations? Usually such rules are driven by one of the previously listed reasons for documenting, but the legal or professional licensure impacts of noncompliance with mandatory requirements warrant a separate category.|
|Other||What else is driving your desire to document?|
|Are you an anal-retentive control freak who has to have everything your way? Maybe that’s OK. Just be clear about what constitutes “your way” by writing it down so that your colleagues don’t have to read your mind!|
2. Weigh the Factors
Assign each of these motivators a weight representing how important it is to your organization right now. A simple scale will do:
3. Produce a Procedure Inventory
Using the list of drivers as a guide to discovery, generate a list of undocumented procedures. You can start by listing those that come to mind quickly, but it’s easy to forget important items that may happen only occasionally or are handled by someone else, so you use the following sources of documentation to help you and your team surface relevant procedures.
|Strategic Plan||If you’ve done mission-driven planning, you may have strategic objectives that imply recurring processes required to achieve them.|
|Project/Task Lists||Review your current and completed projects and tasks. Which of these reveal repeating procedures?|
|Position Descriptions||Review the roles and duties in each job description. Each duty doubtless has one or more recurring procedures associated with it.|
|Service Portfolios||Service-oriented departments may already publish lists of services delivered, each of which is underpinned by many processes.|
|Organization Chart||A scan of your organization structure may spark deliverables produced by departments or teams and underpinning processes that aren’t already captured by a position description and service portfolio review.|
|Planning Calendars||Look at your “tickler” file or planning calendar for recurring processes.|
|Inventories||Asset lists of all kinds, including fixed asset inventories and hardware and software databases, should reveal many recurring procedures, as each of these resources should be employed to produce something for the organization, which implies one or more processes, as well as require some processes to support and maintain.|
Distribute your draft list of procedures to your team to see what additions they can produce from their tacit knowledge.
4. Rank Order Results
To get the most leverage from your efforts, you now need to prioritize the list so that the most important procedures are documented first. One way to do this is to combine the weights for the documentation drivers you generated in the first step with estimates of the frequency of use of each procedure, the probability of having a driver-related issue with each procedure, and the impact of such an issue.
|Driver||Likelihood Question||Impact Question|
|Error-Proofing||What is the probability not following the procedure will lead to a defective outcome?||What is the impact (in relative monetary terms, if possible) of such a defective outcome?|
|Efficiency||What is the probability not following the procedure will lead to lost time?||What is the relative incremental monetary cost of the lost time?|
|Delegation||What is the probability not delegating the procedure will lead to increased cost or constrain critical tasks?||What is the relative salary differential for the time taken and/or the opportunity cost of the delayed critical work?|
|Training||What is the probability the training will take longer without documentation?||What is the relative incremental monetary cost of the trainer’s salary for that extra training time?|
|Continuity||What is the probability the procedure cannot be performed because the resource is not available?||What is the impact (in relative monetary costs, if possible) of the procedure not being performed?|
|Compliance||What is the probability an audit or inquiry will reveal non-compliance?||What is the impact (in relative fines, if possible) of the non-compliance?|
|Other||What is the probability the factor will occur?||What is the impact (in relative monetary costs, if possible) of the factor occurring?|
Multiplying Probability times Impact produces a “heat map” of procedure priorities.
To scaffold this sort of prioritization analysis, I’ve created a procedure documentation prioritization matrix. It’s still a work-in-progress, so no guarantees on its utility. However, if you decide to try it out, please send me your feedback so I can turn it into a useful tool.
5. Plan Your Process
Now that you have a prioritized procedure list, plan the work accordingly. Future posts will provide best practices for creating procedure documentation, but here are some tips to get started:
- Establish Standards: If you don’t have an automated system in place to allow for standardization and sharing of your procedures, begin by creating an “SOP for SOPs” that describes at least in general terms shared standards for your procedure documentation, including such elements as storage location, responsibility, review cycle, style guide, template(s).
- Assign Accountability: Designate one person to be responsible for creating each procedure. This person may need to enlist the help of other stakeholders to provide complete documentation, but having a point person increases the likelihood of completion.
- Determine Deadlines: As with all work, set a realistic deadline for the documentation to be completed and follow-up to ensure the person has the time resources to complete the task.
- Enforce Editing: Since much documentation is used by others, it’s important that the author subject the work to review by others, preferably those who may need to use the documentation, to ensure that it is understandable.
- Incentivize Use: The biggest problem with documenting standard operating procedures is that they too often sit unread, negating any benefit the documentation could provide. Workflow systems solve this problem by integrating SOPs into routine work but you should also find ways to incentivize use by measuring the outcomes of the work processes to ensure the driving factors you identified are indeed trending favorably.
- Review Regularly: Work changes frequently, so be sure to set regular review cycles for your documentation to be sure it’s up-to-date. If you’ve done a good job ensuring compliance with documentation and reviewing outcomes regularly, this will happen naturally, since discrepancies between the documentation and practice will be obvious to those carrying out the work.
Good luck getting documented! Please share your successes and challenges in the comments section.