Technical writing isn't just about writing, it's also about visualization. This client's pain point was in trying to plan the creation of their software products, without the benefit of a firmly defined Product Development Life Cycle. Prior to my arrival, they were trying to do this via Excel spreadsheets, and it was not going well. So I helped them to get their heads around the full process of building new products, in addition to writing their Change Management and Software Development policies.
As is often the case, when approaching a problem, we tend to gravitate to what we know. Being delightful business nerds, these clients naturally tried to map this set of ideas into software they knew, so they attempted to document their processes within an Excel grid consisting of rows of personnel performing the tasks, contrasted with the individual tasks they were performing, represented in columns.
This document became so unweildy, that when I tried to first unpack what was going on, I couldn't even view the entire document onscreen. Even printed on regular paper, the text within the cells were so small, it was basically illegible. So I printed this table out in chunks onto the largest available paper I could find, and literally taped it up onto the wall like a puzzle. By the end, it took up an entire span of one wall in my office, which was roughly 30 ft-wide. No wonder they were having trouble visualizing the problem. They literally couldn't SEE it.
Part of creating useful informational graphics, is to help others see the forest for the trees. In today's world, we're heaviliy siloed into our respective specialities, and therefore it's far more difficult to get a sense of an overall process, or another person's perspective.
A table allowed them to see "Who" was doing "What", but it obscured "When" they were doing these tasks relative to each other, and gave no indication as to what dependencies there were BETWEEN those tasks. A table simply couldn't encompass that level of complex communication. So I took the information out of this table, and made it graphical. The image below is the final result. As you can see, now at a single glance, you can get the gist of things.
+ The entire Product Development Life Cycle is broken up into 7 Phases (Conceptualization, Definition, Product Planning, Development, Evaluate, Go Live, and Innovate/Iterate).
+ Each Phase has Subsections represented as nodes with directional dependencies shown as Arrows.
+ Within each Subsection, are a series of titled Task Blocks, each numbered in the order in which they must occur.
+ Each of these blocks are connected to colored Hexagons, which symbolize the various departments within the company, as defined in the Key on the bottom-left.
+ If a white Connector Line is drawn between the Task Block and a Hexagon, it means that someone within that department is responsible for completing at least one aspect of that Task.
+ Additionally, this graph illuminates at what point various Change Management processes must kick in, notated as yellow block/text in the bottom left of any relevant Subsection node.
+ Finally, the entire thing reads left-to-right, across a Timeline span.
What becomes readily obvious, is where bottlenecks are occurring – either too many departments are focused on one task, or many departments are waiting on one department to complete huge tasks, or a few departments are overwhelmed by many tasks. This was a big success in helping the client to define their challenges, and find efficiency solutions to streamline their processes.
