In this post:
I think about and discuss the potential and use of the humble flowchart.
—
While joining the Air Force was one of my long-time interests as a child, it was not the first and certainly has not been the last.
I am actively pursuing my writing interests. This blog series is one demonstration of that.
I have always wanted to create a video game, but until last month, I never really took steps to pursue that interest.
I started looking into what skills go into making a video game, which alongside needs for graphical assets and audio effects, I found myself seeking a game engine.
The search for a game engine brought me to Godot.
In examining introductory material on how to use Godot, I found a link to Harvard’s CS50x course.
I’ve only finished two of the eleven weeks so far, but I’ve found that I’ve been almost comically obsessed with thinking about things as series of flow charts, and figured that must be this month’s topic.
—
The introductory webpage for CS50 provides an excellent example of the topic I want to touch upon with a workflow image:
Figure: The “How to Take this Course” Recommended Weekly Workflow
—
What is a Flow Chart?
Now, I’m not saying the concept of flow charts is new or groundbreaking. However, working from flowcharts is a great way to trudge through a problem.
Constructing flowcharts can be broken down into two major parts: Nodes and Transitions.
Nodes generally encapsulate a singular action, while Transitions indicate interfaces between Nodes.
As an example, the process of writing out my blog posts could easily be set through a flow chart:
Figure: Simple Flow Chart for Writing An Airman’s Writing
Nodes are represented here by the colored blocks, and the arrows represent Transitions.
In the above example, “Select a Topic” is a single action. When that action is complete, there is only one follow-on action, so this Transition is as simple as can be from Node 1: Select a Topic to Node 2: Draft an Outline.
Another example comes to mind from Lethal Company:
Figure: Playing Lethal Company in a Flow Chart
Here, the Nodes are also graphically placed within defined environments that are also Nodes.
The Nodes represent the actions that a player (i.e. an Employee) can take and are designed here to also indicate where in the game world the player is taking those actions.
There are multiple Transitions. The more obvious ones are represented in orange and indicate Transition between physical spaces. The less apparent transitions are represented by the shared boundaries of the Nodes themselves.
Whenever a “Day” Starts, players begin Navigating the Ship. From this starting Node, the player can transition to anything else within the Navigate The Ship block or Transition via Ship Door to Navigate the Exterior of the moon.
So, rather than the serial flowchart of writing one of these blog posts, the above demonstrates the vastly more flexible nature of playing a game. You will also notice that it is still fairly (but not entirely) comprehensive despite its simplicity.
For those familiar with the game, you also know that most of the above nodes may also have their own expansions of nodes within them…
—
How to Flow Chart
Now, while Nodes and Transitions are the apparent building blocks of a process flow chart, how do you identify or design them for a project?
The development of a process chart varies depending on whatever you are trying to do and/or dependent upon whomever you are trying to offer the chart to.
I’m finishing up an assignment as an executive officer right now.
Among my myriad tasks, I am responsible for spot-checking my entire organization’s annual military evaluations and collecting stratification “push comments” from the relevant members’ Raters for my boss.
If I were to treat this as a brand new task, I’d try to identify the End State and any necessary Tasks to get my flow chart started:
Draft 1 Major Points and Notes.
End State: Boss receives (1) Evaluations and (2) Stratification Comments
- Evaluations are spot-checked for simpler errors
- Stratification Comments have minimum required content
Both Items must be collected from Raters.
Many Raters have their own administrators that serve as the contact point.
There are three different ranks for this specific iteration of evaluations/ stratifications that do not intersect.
This may be enough to draw up a first draft, after which we make additions to shore up gaps in the process:
Figure: Simple Draft of the Evaluation Process, Executive Officer Perspective
Now, let’s say I finish my assignment before I can update my draft.
While I know how this works without having a process available to me, could my replacement use this alone or would further improvements be necessary?
Perhaps someone else got a hold of this chart but they are not the Executive Officer. If they are one of the Subordinate Admins or one of the Raters, what might they want to know about this process?
Back to just the Executive Officer’s perspective: The Review Documents Node could probably use more detail in a next draft: Maybe there is a checklist of review activities that could inform the node – there would certainly be something like that if there was ever a desire for greater automation of this process.
Perhaps updating the Process Flow Chart with Specific Admin Names would be important, especially since a new Exec might not know who the Admin members are.
Perhaps naming the specific Documents to be requested is important, since the Evaluation and Stratification Documents are, in natural bureaucratic fashion, on specifically named forms or are strictly online or, without guidance, might appear on a napkin or Excel spreadsheet, etc.
I’m not going to put together a second draft here, but hopefully you get it.
—
Why to Flow Chart
Maybe you wonder “Why might this be at all valuable?” or “Why should I care about this?”
The best argument I have is that it’s often much easier to design change when you can visualize it, especially if you’re trying to do so in a team. Specifically, you can share what you have in mind, and you and your team can more easily recognize gaps.
Trying to improve something? It’s easier to recognize your opportunity spaces or bottlenecks visually.
Trying to do something entirely new? It’s easier to identify your required steps in defined representations rather than sheer, listed thoughts.
Trying to do either of the above with a team? Sharing a visual is generally more effective than talking it out by voice or text.
—
What do you think?
Do you have any projects in mind that might benefit from the use of Flow Charts?
Got any team members that are already using Flow Charts that would say whether they are actually useful or just a preferential tool, etc.?
72 Airman's Writings 