Quite often a written problem statement or meetings to discuss a challenge a project or team is facing seems the most expedient response to attempt to solve the problem- or at minimum to brainstorm solution.
The inherent challenge with this approach is that it assumes all attendees and conversationalists are on the same level of communication skills and preceptive interpretation, not to mention listening skills.
Thankfully Humans vary and all people tend to favor a specific way of learning/interpreting/understanding a situation. Although most use a combination, they do however interpret differently based on their primary mode of learning.
Kinesthetic – these people tend to prefer doing – physically. In the case of understanding a problem that needs to be solved they should be acting out the challenge that needs to be overcome – to feel the resistance per se. “Walking a mile in the other’s shoes” if you will to truly have their creativity engaged and desire to change the challenge thus feeling the pain of the challenge.
Verbal – this obviously is the most common way people use to discuss challenges, but not necessarily the best only approach to take. Most People are operating on auto pilot; ~95% of their day actually some studies show. That means there are so many other things that they are pre-occupied about instead of the challenge you would like to improve. They’re thinking about the next deadline, how much they dislike you or maybe someone else in the room, how they can improve something that’s effecting them and their work, how to make more money, how this challenge or its solution go over politically, etc, etc… Your job is to make it relatable, by employing other methods of “what’s in it for me”. To engage these folks think through the challenge in your project and how it can benefit their project directly or a personal mission they’d like to take on to improve personally.
Auditory – this of course is the hearing faculty and is so very much dependent upon the actual specific words used, the tone of the speaker and verbal personality of delivering the problem statement. Again, as stated above it’s biased and filtered through the person’s 95% of automated actions, behaviors and logic. Listen to the selection of words and how many are used. The more long, drawn out the steps are in the challenge, the better the solution sounds when the solution has less steps.
So how do we actually apply the understanding of HOW people learn and their differences to affect the outcome of a solution?
Well, here comes the Entity Relationship Diagram (ERD), I started using them a long time ago when working with databases, Informix 4GL to be exact. They do exactly what the name suggests- they show you the relationship between steps or users, or actions; whether they are system (automatic) actions or user actions (manual).
I think they really do save a lot of text/time simply by using a picture. They can address most challenges by creating a story of the problem pictoraly allowing the solution to be weighed objectively and avoid lots of the issues described above or at least any counter argument will quickly uncover a true miss in the process or a political/personal ploy as to why (budget and resources would be considered as something that should be determined as part of the overall solution. i.e. may be able to automate in stages vs. all at once.)
This ERD mapping can be done for any business process regardless of industry to identify room for improvement. Although is it often used in Software Engineering it can be used for manual process reviews as well.
Don’t overcomplicate it
The Standard ERD shapes are significant and describe an action simply by its shape. Here is an example (just a few, there are many more):
Although there are standard ones, don’t get caught up in getting it perfectly right- just use the diamond for decision, everything else, just use whatever is easy to remember.
Now for the arrows: one headed arrow signifies a one-way flow or action. The double headed arrow signifies action is reciprocal in some manner or can flow both ways (in and out)
Let’s look at a case study
Due to continued student complaints at a major university uncovered the process of obtaining a parking permit to be difficult, long, inefficient, time consuming and every other bad adjective. The administration wanted to make it easier, more efficient and allow for historical electronic recording.