Aligning Narratives with Process Maps

After nearly 30 years of technical writing and nearly 20 years working on Process Improvement projects, I’ve noticed a disconnect between the process project and the documentation of the project. I have developed a proven method of documenting process projects in which the accompanying documentation is developed, edited, Baselined, and archived such a way that they are well aligned and provide necessary information to perform the tasks.

It is not enough to simply map out an organization’s business processes: they must also be accompanied by well-written documentation that serve as companion deliverables to the actual process maps, which I typically call the “Narratives”. Not many people understand the importance of this, nor do they correctly align their narratives with their processes. This is a common oversight, but one that must be addressed: users of process maps must also have access to the explanatory material that goes into greater detail on the process maps to provide clarification, deeper understanding, the rationale behind the process, caveats, and anything else that will help the process performer perform his or her duties in accordance with the process.

Understanding Process Levels

No discussion of process documentation would be complete without an understanding of process levels. When I’m on a consulting project, I oftentimes ask the client at what level they would like their processes mapped. In nearly every case, they don’t know the answer, or even what I mean by “process level”. This is not a trick question; rather, it is a way for me to determine their understanding of business processes, and provides a guideline to help me set a roadmap. If they don’t know the answer, then my job is to help them understand what process levels are, and how they fit into the organization’s processes. There are five levels of processes, although in practice I have rarely seen anything beyond Level 4. Here is a brief summary of process levels and what they mean:

Level 0 – The highest level; usually just one or two steps and occurs at the Director level. This is typically parallel to an org chart, and lays out the high level organizational structure.

Level 1 – The second-highest level; usually describes high-level tasks for managing the processes of an organization or department. Processes at this level are often used to provide clarity for management and employees, and to set guidelines regarding the boundaries of authority (i.e., who reports to whom, what decisions are made at this level, etc.)

Level 2 – The most common type; illustrates the general tasks and handoffs required to produce a deliverable and/or a specific outcome. Processes at this level are very useful in laying out the tasks that are crucial to the performance of the task.

Level 3 – Oftentimes known as “Desktop Procedures,” and describes each main task and how to perform it. A Level 3 process is often used to train new personnel. In theory, a well-documented Level 3 process would enable a new employee to perform the duties of the job with little or no supervision.

Levels 4 & 5 – Represent the most amount of detail possible, and can include hundreds of steps. At this level, every task, however minor, is represented. Processes at this level are often found in laboratories, high security operations, and processes in which human life is at risk. Hence, nuclear power plants and manned space programs will have Level 4 & 5 processes.

Sample Level 3 Process Map

The example illustrates a Level 3 Interview Scheduling process. Note that the functions are shown on the left, the tasks are numbered, and the systems used are indicated by icons next to the respective tasks. The diamond-shaped icons represent Decision Points, in which the task(s) may differ depending upon which criteria are met.

 

Process Narrative Layout

How the narrative is structured is important: I include a table that includes the number, description, function, and deliverables for each task. Always number each task to align it with the tasks in the process map. I use tables to describe each task, and include columns to indicate the task number, description, function (who performs the task), and the deliverables. The description column may include notations which provide further explanation information regarding the task. This can be very helpful in providing clarity, as well as caveats (do’s & don’ts, what to watch out for, etc.). The sample shown here illustrates this.

Aligning the Documentation to the Process

At each level, the narrative should align with the process in such a way that each task is linked to its explanation in the narrative. The illustration below shows how this is done:

At this phase, input from the actual performers of the processes is crucial: these are the people who know more than anyone about how the tasks should be performed, and they are your best resource. Furthermore, they should be a part of the review team to provide feedback on the content, ensuring completeness and accuracy.

Finally, you should link the process map with the narrative such that the user can click on any task in the map and bring up the narrative. You can do this by linking individual tasks with the respective task in the narrative, or simply link the entire narrative.

A future article will address version control, which is an important component in the documentation process.