The value of process mapping

Process mapping and "flow charting" are essentially synonymous

In the beginning... 📖

At work, for the last couple of years, our team has been busy producing documentation. Mainly engineering-related design documents. At this point, I wouldn’t be surprised if over 2000 individual documents have been produced — and we are nowhere near finishing.

The process

When this work began, I defined a simple process for how these documents would flow through the different teams. That process looked something like this:

  1. Our engineers produced the documents 📝
  2. Our engineers peer-reviewed the documents 👀
  3. Our technical writers reviewed the documents (that’s me) 👀
  4. Our project managers sent the documents to the customer 📨

That is a huge over-simplification (there is probably closer to 20 individual steps), but it gives the general idea. To help visualize what stage each document was in, I created a series of folders. These folders were named as such:

  1. Create Document
  2. Engineering Review
  3. Technical Writing Review
  4. Send to Customer
  5. Wait for Approval
  6. Document Approved

The documents would then move through these folders based on the stage of their development. If the customer requested modifications to the documents, those documents would move from the “Wait for Approval” folder back to the “Engineering Review” folder and move through the process again. And once a document was fully approved, it would be moved to the appropriate permanent storage location.

All of that worked relatively smooth. But then... 😟

The modified process

Due to the extensive amount of work, our team couldn’t keep up with the creation of the documents. Rather than hire more team members, it was decided that we would contract out the work to engineering firms (our vendors).

This introduced a bit of complexity because now we had to get the documents from the vendors. Due to the confidential-nature of this work, the folders I created for the process above were not accessible to the vendors. So, it was decided that we would use secured cloud storage. This new process looked a bit like this:

  1. Vendor produces the documents 📝
  2. Vendor uploads the documents to cloud storage 📨
  3. Our project managers make copies of the documents ✉️✉️
  4. Our project managers upload the copies to our internal storage 📨
  5. Then the original steps above are performed (skipping step 1) ☝🏼

This is our current process, and it worked for a bit. But then...

Tragedy struck 😱

Well... not exactly a tragedy, but still. I discovered a new problem with the current process.

All of the documents the vendors produce are reviewed by our engineers and technical writers. During those stages of the process, small modifications are made to the documents before they are sent to the customer.

Speaking specifically to the technical writing-related modifications (seeing as that is my responsibility), I might make the following adjustments:

  • Correct improper grammar
  • Correct improper spelling
  • Correct improper formatting
  • Adjust for ease-of-use
  • Adjust for consistency
  • Adjust for accessibility

The problem (i.e., the tragedy)

Our customers almost always request changes to the documents (if I had to guess, at least 8 out of 10 documents come back for revisions). The requested changes are sent to our project managers, who notify our engineers, who notify the vendors. The vendors then update their copies of the documents.

Do you see the problem? 🤔

Our copies of the documents which have undergone small changes since being received from the vendors are not the copies that the vendors update when changes are requested (they don’t have access to those after all). So when the vendors update their documents and send them to us again, our engineers and technical writers (me) have to make all the same modifications.

Each document undergoes around 1-2 hours of review and modifications. But, when those updated versions are not sent back to the vendors when changes are requested, those 1-2 hours are meaningless, because they have to be repeated. And our customers will often request changes many times 😒

Therefore, some of these documents that would typically undergo 1-2 hours of review by our team are now up to 4-8 hours, simply because we are repeating the same review and minor modifications over, and over, and over, and over.

But wait… 🧐

Now you might be wondering, why hasn’t someone noticed this? Wouldn’t we realize that we keep making the same minor modifications to the same documents over, and over, and over again?

Well, no.

There are so many documents that they kind of all just blend together at this point (at least from my perspective they do). In addition, and I regret putting any one team on the spot, but our project managers are the ones tracking this stuff and this issue is going unnoticed by them. In fact, our project managers are oftentimes compounding the issue.

This week, for example, I worked on several documents making minor formatting adjustments, but I didn’t finish them all because I was reassigned to a more important task. After finishing that task, I went back to finish those other documents and discovered that the ones I had finished had been permanently overwritten by our project managers with new versions from the vendors. All that work, gone 😡

Conclusion: Use process mapping!

With so many teams involved in a single process, one with a great number of steps, it is important to clearly map and periodically adjust (i.e., improve) the process. That is where process mapping and process improvement come in!

You can probably find a bunch of complex definitions online for what process mapping is, but essentially it is exactly what it sounds like: the mapping or visualization of a process from start to finish (typically via the use of a flow chart).

The process could be related to anything. For example, it might be a software development process, or a supply chain process, or product development process, or (like the above story) a documentation process. There is no limit to what could be mapped 😲

The takeaway is that, if the above process had been mapped (which I did originally) and had been adjusted as the process was modified (which wasn’t done), we likely would have recognized an issue: that when documents are sent back for revisions, our adjustments are being overwritten and repeated.

But now that it has been noticed (better late than never), we can start improving the process 🥳

Note: Process mapping and improvement is not typically the responsibility of a technical writer — if anything, it should be the responsibility of our project managers (or business analysts if we had them) — but it is something I enjoy and see the value of, so I take responsibility for it. Also, I’ve come to realize, if I don’t do it, know one will.