Technical Process Discovery: The Case for a Dedicated Documentation Specialist by Eric Sedor

Without sequencing tasks to a specific purpose, the commonplace actions that constitute office work make little sense and no one would sit around all day doing them, ever. We all recognize the need for processes, but that’s generally where agreement ends.

As process is of fundamental importance, is it any wonder such effort is put into process documentation? Is it any surprise that these “action highways” often languish in some state of reconstruction or another? Tomes invariably groan under strain as workers struggle to maintain them, or they waste away in untravelled disrepair in some unvisitied shared folder, leaving process participants to their own devices.

The process is an ephemeral beast that all its participants glimpse in part. Often process documents are updated through collaboration between participants, but even this is difficult, if for no other reason than that participants are busy performing the process, and taking time to write about it doesn’t seem to help.

The Process Document

Process documents overarch mere specifications and user guides. They exist in a broader space than specific tasks and explain the causal relationship between tasks across multiple actors, disciplines, and teams.

Most readers make the mistake of equating processes and process documents. “What is written is the process,” and “If it isn’t written down, it’s not a process” are common maxims. Those maxims are helpful to an extent, but one must not confuse one for the other in the quest for rigorous documentation. Process exists in the abstract and is simply what people do to get the job done. Process documents quantify processes. A document can be helpful in executing the process, outright wrong about the process, or anything inbetween.

A process does not become a process when it is documented. A process becomes a process when it is agreed upon by its participants. To the extent that agreement is complete and accurate, the process can be documented easily, but rarely do individuals have enough information to agree to the same reading of the same document. It doesn’t work in religion, and it doesn’t work in corporations.

It Doesn’t Have To Be This Way

Given the potential for disagreement, we expect bad process documentation and/or bad processes to occur often. And they do. What is surprising, instead, is how easy it is for process documentation to be so quietly unhelpful that it escapes meaningful blame while paradoxically serving as a scapegoat for the process itself.

In so many horrific cases, the labor force has come to believe that process documentation is always going to suck.

If you already believe this for one reason or another, even through some seemingly benign and technocratic justification like “oh well uh it’s an evolving, agile, uh… always improving something… “, then set aside that conviction for a moment and trust that everyone in your annoyed, annoying department wants to be happy when they come to work every day. Consider that a better process and better process documents can help.

To the extent that processes diverge from and conflict with the continuity of daily activity, every participant (and knowing recipient) of the process loses confidence and suffers a morale deficit. The term morale deficit, here, is used to mean the awareness of a logical or emotional inconsistency which must be explained away (justly or unjustly), or perhaps ignored in frustration at some accumulating morale cost, for work to continue normally.

Having good process documentation is not just about the process. To the extent that process documents do not enable legal accountability for wrongful action to be determined quickly and painlessly, everyone responsible for explaining the process to any wronged party–and everyone listening to that explanation–loses confidence and suffers a morale deficit. The company becomes unable to protect itself legally or satisfy legal requirements because as an actor it does not know itself well enough to explain itself to others.

When the process is bad or the process documentation is inaccurate, inconsistent, or blatantly unhelpful, the environment suffers. If you look hard enough, you may even start to see that when there is suffering in the environment, there are inaccurate, inconsistent, or blatantly unhelpful process documents.

Process Documents Are Signs, Not Roads

Process and process documents are related, but must be viewed as independent items in symbiosis, not a two-headed conjoined abomination.

How many times have you been sitting in traffic thinking how nice it would be if everyone just followed the signs? By contrast, how often have you wondered how nice it would be if the signs were easy to follow? Can you imagine the chaos if 3 miles of interstate signs were simply wrong? When you are driving, how often do you take the accuracy of your GPS for granted?

If a process is the highway network on which work is performed, it is interesting to think of process documents as providing insight into the infrastructure, not as representing the infrastructure itself.

By viewing process documents as distinct from processes, many more conflicts become visible during difficulty. Here are a few examples:

Worker vs. Process – The consumers of the process document do not agree with the process and circumvent it.

• Process vs. Process – Two processes conflict with each other, leading to confusion.
• Process vs. Worker – The process itself is detrimental to productivity and morale.
• Process vs. Document – The process is detrimental to the maintenance or usability of the process document itself.
• Document vs. Process – The document is wrong, misleading, or generally detrimental to the process itself.
• Worker vs. Document – Important changes to process documents are neglected by the workforce.
• Document vs. Worker – The document is so difficult to update that it becomes an unwelcome chore.

Without the distinction between Process and Document, you can see how all of these conflicts could be conflated together into just a few conflicts and it would mostly appear as though you simply had employees who didn’t do what they were told.

The Frontier

The last time something went wrong, how many people did you have to meet with to understand it?

For some managers or process stakeholders seeking clarity during moments of chaos, it is enough to value the process document. Their example ensures the document is treated properly. But what about the rest of us? Simply thinking about process and the process documents “separate but related” is a start, but unfortunately in so many cases these thoughts unravel quickly. Something as simple as “I wonder if Shirley has what she needs” can easily become “There is no way Shirley is making it through this process without cutting a corner. Is this a satisfactory means of improving efficiency?” But before you finish asking the question, the latest fire in QA has to be put out and 4 managers need to meet to sign off on a change, so that’s the end of that inquiry. Good luck, Shirley.

The bad news is you probably can’t fix it alone. Process documentation necessarily involves coordinating a team. In fact, it is so fundamental that creating a process document is more aptly the differential act of coordinating coordination itself.

That’s probably a little much for you given your other responsibilities. You need help. And a product manager with time to spare isn’t the help you need.

You need a process discoverer.

Process Discovery

Approaching workplace efficiency from a process perspective requires acknowledgement of something radical, especially given the incorporeal nature of process. Process is a product. As with any product, a good process is not produced when everyone involved only does a little bit of work. Someone has to be responsible for aggregating information and facilitating decisionmaking about the product, don’t they? Some important products have entire teams of people who are solely responsible for the product’s direction. And what is more important than the underlying processes that turn otherwise meaningless discussion into useful work?

Process discovery recognizes that processes exist in a three- or four-dimensional space, not just the 2-dimensional space that documents are written on. To reasonably observe an object in the third dimension, you need at least 3 vantage points. How many vantage points exist over your processes? The stakeholder’s view and the participant’s, perhaps?

Unless you have a process discoverer on-staff, the answer is likely two. One less than the number of legs a good stool requires. Welcome to the frontier where there are no roads, just signs planted near paths.

The concept of process discovery recognizes that processes aren’t dictated so much as they are born from a combination of practical needs and accountability needs. A process discoveror walks into a situation believing as much in Shirley as in the document. This is because–all metaphor aside–Shirley actually does the work, and the document doesn’t. The discoverer knows that when accountability is required, the readers of the document will be sussing events, not the document.

The discoverer, then, is extremely interested in the consistency, accuracy, and usability of the process document, as well as the process itself. A proper process discoverer is skilled in identifying conflicts and bringing them to the attention of others for correction.

Technical Writing as Process Discovery

Technical writers are perfect process discoverers, because they are necessarily experienced in detailed documents and the relationship between those documents and whatever it is the documents describe.

Do you have unfulfilled documentation requirements right now? That’s a rhetorical question. The answer is yes. You have unfulfilled documentation requirements that are preventing your team or department from moving to the next level in morale and performance. Your process documents do not reflect the actual work being done. They aren’t easy to read or update. And in some places they’re just plain wrong.

This isn’t about getting a technical writer into your department to fix your documents and leave. This is about using a dedicated technical communication specialist as:

• A 3^rd, integrating point of observation in an otherwise 2-point (Stakeholder/Participant) system.
• A custodian of the documents themselves, saving other personnel resources for the tasks to which they are dedicated.
• An investigator capable of interacting with all participants and stakeholders to aggregate the best of all worlds and bring the worst inconsistencies to the surface sooner rather than later.
• A steward of the processes themselves, combining investigation, custodianship, and integrated observation to assist stakeholders in the employment of effective processes that workers prefer over unusable processes that cause strain.

The good news about a dedicated technical writer—especially a technology-savvy one–is that their skillset allows them to be valuable any time any document is involved in the work place. That’s 100% of the time, by the way.

What we’re talking about here is someone whose full-time (or part-time non-temp) job is to perform technical communication about work processes. If your business needs agility, accuracy, and a well-trained workforce with good morale, there is nothing more beneficial to you than having documentation that is updated quickly by a skilled, dedicated professional.