Effective Communication Skills: Process Mapping

Before you start, understand the big picture. I have often asked the people closest to the operation, "How do things work around here?" You need to understand the larger process conceptually, but not yet in great detail. Ask open ended questions such as "Can you give me a general idea of how this works?" Stay open-ended and stay general. You'll dig for more detail later.

Next, identify the start and end points. If you have a large process, break it into smaller, manageable pieces. Use the Start and End points as "bookends." As you dig deeper and go into more detail, you may have to move the bookends, and that's OK. Your goal here is to break your large process into manageable chuncks.

You will need some supplies:

• Post-its or Stickies. Either will work.
• Chart paper or brown paper.
• Markers
• Scotch Tape or masking tape (Sometimes the Post-its fall)

Determine all the stakeholders, then find who's involved in the process.

1. Make a list of every FUNCTION that is involved in, affect by, or has influence on the process you want to analyze. Be sure to use functions and job titles – vice president, safety pro, engineer, operator, admin assistant – instead of specific names. Using names leads to people getting unfairly blamed for problems in the operating systems.
2. Select those directly involved in the process. Start with the main players. As you dig deeper, you might have to add a few more functions to the map.
3. Assign each player a swimlane. I usually start in reverse managerial order (Operator, next line is Supervisor, below Supervisor is Manager, etc.) but it's just a starting point - You will move these lanes several time. Your goal is to make the map as clear as possible, so it's OK to rearrange…that's why we use Post-It's.

Here's the fun part. This step is where you learn how things REALLY work. When you have the stakeholder (or better yet, the stakeholders) start mapping the process. You can start by saying, "Folks, tell me the first thing that happens." You will also hear yourself ask several times, "OK, what happens next?"

There are several best practices:

• Understand what you're analyzing. Are you mapping an "as-is" map or a "future state" map? Be careful when making the "As-is": Many will try to tell you what's supposed to happen instead of how things really are.
• Ideally, you'll get all the people together when you make the first draft of the map. However, it's not always possible to do so.
• To get started, use Process Blocks, Decision Blocks and Subprocesses. As you get more experience, you can add more shapes and tools. At first, don't get too bogged down into the details. Do that on a second or third pass, and make use of subprocesses.
• You might choose to number the steps, especially when you have a more complex map with many comments.

Validate, validate, validate. Verify, verify, verify. Most likely you won't get all the players together, so you'll have to validate your map with the other functions and stakeholders. Take your map to the people involved and have a discussion. Ask if it's accurate. Most likely they will learn something and be thankful that you discovered it.

Every business process – whether it's an "as-is" or a "to-be" process – has at least three versions:

• What's supposed to happen.
• What really happens.
• What we think happens….and there will be many versions.

In the example we're using for this class, we focus on the "What really happens." Typically, there will be disagreements or differing views on 10 – 15% of the map. That's good…it means you're on your way to uncovering the trouble spots.

You will find trouble areas, and the causes are usually not where you'd expect them to be. I've found that a root cause analysis works very well with a process map. The areas where you found disagreement are often the areas where you'll find probably where you'll find your problems.

Remember your task: You know that the employees are not the problem. You feel that Operations MUST fix the spare parts issue, and you must communicate this finding to the bosses. How can you "sell" this idea to the Depot Manager and the COO?

We used the "5 Whys" to dig a bit deeper, and found a reason that would cause a driver to get a late start. It happened quite frequently:

• Why? The driver had to spend time getting a new bus.
• Why? Because the horn frequently doesn't work and it's illegal to operate.
• Why? Because the mechanics didn't fix it.
• Why? Because they can't get the correct parts, and they can't get them promptly.
• Why? Because purchasing doesn't know about the problem.

(*** Root Cause Analysis is a bit out of scope for this class, but we are considering creating a new Udemy course.)

Now the easy part… You don't need to be a phenomenal speaker if you're armed with a really good process map. Simply walk people through the map. Would you rather give a presentation or have a discussion? You're generally much more effective with the latter.

*** We'd love your feedback and also suggestions for new courses. We're considering a new Udemy course, "The 5 Whys Method for Root Cause Analysis." If you like this idea or have any others you like to share, please contact me at gadelsberg@communicationforgeeks.com.