Execution - Erase "MAYBE" from your lexicon...

The following is the original and the rewrite can be found by clicking here.

If you know anyone who has come out of the General Electric "machine", you will have undoubtedly heard of, and/or experienced a "Workout". The original workouts came into being as Jack Welsh, the CEO, was working to right General Electric; they went something like this*. A team (without the leader) would meet to review all the issues that needed to be answered to progress various projects, mandates or agendas forward. The leader would then join them and systematically answer their questions with "YES do it", or "NO don't do it", or "I will get back to you with a YES or NO answer in a week". This implemented action.

There is a "truism" regarding effective execution - All action is derived from either the word "YES" or the word "NO" -  any other word will lead to a vast array of inaction. As a quick illustration**, lets look at the manual outlining what to do if you see a strange "flying saucer like thing" in the air. I'm sure it doesn't read like this:

• "YES" push the red emergency button. (action)
• "NO" don't push the red emergency button. (action)
• "MAYBE" push the red emergency button. (what exactly do you do with this?) 

If you look at any process map or decision tree, there is never the option to choose "MAYBE"... it is very hard to know what action to dive next when you hear the word "MAYBE" (or any derivation of it). About now, someone may be saying, "Wait a second, sometimes you have to say "maybe" because of a lack of information, poor timing, lack of resources, etc". These reasons, really justifying saying "NO", with a perspective as to what action is needed next to stop what is being done, or to garner a YES decision. "YES" and "NO" drive the process forward... "MAYBE" keeps everything in a holding pattern - Spinning and spinning.

"YES" and "NO" are also great data points to measure execution effectiveness. The more you find "NO" being used as part of the decision making process, the greater chance you may have skill set issues, resource issues, time management issues, misalignment with goals, risk tolerance issues or a culture that struggles to drive action - If you hear "MAYBE", you can guarantee you have one or all of these.

There is also an ambivalence that comes with the word "MAYBE"... it will insidiously compromise decisiveness, which is so important in good leadership and will also feed the emotion of regret; the words "woulda, shoulda, coulda" will stick to you.

So throw the word "MAYBE" away! It will serve you well. Things will get done.

gpe

* I have not experienced the original "Workout" but have been involved in many of its "workout cousins" ... sometimes affectionately called a "deep dive".  I've also simplified this and taken a little artistic licence to stress the point. 

** This flying saucer sighting example struck me funny. Apologies if you didn't think so.

Execution.... the third in a series of thoughts

The following is the original and the rewrite can be found by clicking here.

I had promised I would talk about the fun you can have with process mapping and I think the best segue into this would be to start with "Meeting attendance auto-Pilot", or for those who love acronyms, MaaP*. 

A lifetime ago, in another world, I found myself in a meeting listening to a marketing manager review a promotional initiative that was in "pilot phase". It was here that I slipped into MaaP. I'll take a moment to define it for those not familiar with it - MaaP is the ability to be aware of everything happening in a meeting while mentally tending to the many other things you would be doing if not for the meeting. I should also point out this is not an aspect of disrespect but more a necessity for survival in some companies. I suspect it's comparable to an out of body experience. 

All of a sudden my MaaP drops out of warp drive and I find myself saying, "run that by me again?" It is here that I'm retold how the promotional fulfillment component of the "cool smartphone app promotion" is fulfilled automatically in one case, but in the other instance the fulfillment needs to be done through the sales force. There is some discussion with regard to using the sales force for promotional fulfillment and how it is a bad idea... it distracts the sales force and increases the exposure to having a disappointed customer. The marketing manager points out that it is a "very cool app" and there were few examples of the need for the sales force in the pilot. To that it was pointed out that the pilot would not scale in its current form. The meeting continued and I think I may have slipped back into MaaP.

Example of a simple process map (some get very complicated)

Let's fast forward three months after my MaaP experience... by then, that "app promotion" had rolled out into the market and my role had changed where I was now much closer to the impending storm of "a pissed off sales force and disgruntled customers". As I got into the situation it became clear few people were aware of, or even understood the impending "problem". It was time to develop a process map as to how this promotion worked - Not a bad segue eh?**.

So what is a Process Map? -  A process map is essentially a breakdown of a process to determine how it flows and, ultimately, how effective it is. Those who complete process mapping look closely at elements such as the structure of a system and the flow of communication within the system. It consists of circles, boxes, diamonds and arrows representing the flow. (see diagram)

• The circle (oval, or rounded box) represents the start or end of the process
• The square represents a specific activity as part of the process
• The diamond represents a decision making point (yes or no)
• The arrow represents the flow and the connectors from activity to activity through the decision points.

Here is why I like the process map: 1) it forces you to understand your process and how you do what you do, 2) it is a visual representative, so you can literally see what you are working with and by extension makes communication easier, 3) it makes it much easier to identify problems and gaps in your process and 4) it helps determine optimization, correction and execution.

So now back to the process map of the promotion... well it was so complicated it looked like a "circuit board"; so much so when I was reviewing it with someone they simply looked at me and said, "you've got to be kidding". In the end, this process map made it easier to communicate the situation and illustrate it's impact on the customer, as well as internally. It ultimately led  to process improvement, that, although not perfect, alleviated the immediate issues.

As I look back at this situation and what came out of it, a few things resonate with me still - 

• Development of a process map in the beginning, as well as a better understanding of the systems that you work with***, probably would have driven better execution.
• Smartphone Apps are not a silver bullet.
• No matter how much someone tries to convince themselves that there is not a problem, there is.

There is a great science to process mapping, as well as its close cousin functional excellence, and I have learned over the years that is it is an excellent tool to help you optimize all things involved with execution.

I hope you are finding this series informative, as well as maybe a little entertaining. Let me know.

gpe

* I will be the first to admit that this could just be me, as at the end of the day I have the attention span of a small insect.

** Remember I am Canadian.

*** Understanding the systems that you have available is imperative for optimized execution. It makes me nuts when people try to work outside the functionality of the system at their disposal and then blame the system for any shortcoming. I mean, I wish I had a "matter transfer device" to get around, but I don't so until then I will work with the airline industry.