The Business Gnome

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

It's been a little over 90 days since I have been blogging under the unicorn banner of GPEStratagem and I wanted to quickly say, "Thank you for reading". I also wanted to take a moment to ground us as to what I story tell about - Specifically, I am interested in out of the box thinking as well as creative problem solving, particularly in the areas of sales and marketing; this of course can run the gamut including situation analysis, planning, problem solving, leadership, execution, process improvement, organizational behaviour and of course the customer. With all of this said, it is probably time to mention the rarely seen, but very much believed in, Business Gnome.

I've heard the business Gnome looks like this...

A very dear friend of mine, who I hope is finding great fun and adventure at the moment, introduced me to the Business Gnome a number of years back. For those of you who are not familiar with the Business Gnome, it is a genus of "mystical individuals" who get things done when people don't think of it, assume it'll will get done, don't want to do it, or don't know how. The Business Gnome falls into a number of different species, such as the "Technology" Gnome, the "Marketing" Gnome, the "Clean up your mess" Gnome (which has a domesticated cousin), and so on. Business Gnomes, like "tribbles" (yes a Star Trek reference), are cute and cuddly, but if they get into the machinery they will totally mess up effective execution and most definitely impact your customer's experience.

Let me offer you an example of what I am talking about - A small company was sponsoring an event which involved developing a process to sell the event tickets online and went live with it. It turned out when a customer went to order a ticket, the only option available in the drop down menu was zero. After that was fixed, it became apparent that there was no electronic ticket that was actually sent to the person who had ordered... just a receipt indicating that their credit card had been charged. In all of this, it is obvious that someone looked to the "Technology" Gnome to ensure it all worked when they set up the process. It was a good thing the company was so customer oriented as they caught this with the first order and fixed the situation. They went on to have an amazing event and the Technology Gnome was conspicuously absent. 

As you can appreciate there are two camps regarding the existence of the Business Gnome and I don't want to spend time debating their actual existence but instead spend a little time on the "people and company cultures" that do believe in them... or at least act as if they do. 

People (and cultures) that don't take the customer's perspective in what they do are big believers in the Business Gnome, and look to them to ensure that all of their initiatives and processes work smoothly. To this point let's use the situation with the event tickets above - If, before they went live with the ordering system, someone had said, "Let me pretend I am a customer and see how this works", they would have discovered very quickly that they had some "gaps" in their process, and ultimately in the customer experience. Those who think like customers don't believe in Gnomes.

There also seems to be a correlation with people not knowing the systems and processes that they use and their belief in Gnomes. Many a time I have seen a brilliant idea come crashing into reality because of the limitations of the systems and processes that are available... somewhere, somehow, someone must have had faith in the "Operations" Gnome to make it all work. As an extension to this, there are people who are miscast for the task ahead but "do it anyway", without soliciting help and the resources needed to make it happen. They must be big believers in the "Hope and a Prayer" Gnome. 

And lastly, the biggest playground for Business Gnomes that I have seen is where there is a culture of assumption... Assuming it will get done, assuming the resources are there, assuming the skill sets are in place, assuming the customer thinks like you, assuming there is someone to pick up after you, assuming the system will do what you want it to do, assuming your pilot project will scale - Hopefully you get my drift, and if you find too much assumption going on, you most likely have a deep seeded belief in Gnomes. 

Of course, encouraging Personal Leadership, Ownership and an understanding that everything is connected can create a culture of accountability... dispelling the mythology of the Business Gnome. 

Let me know if you have seen a Gnome, and do remember that "Car Key" Gnomes are very real.

gpe

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. 

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

Lying on a table, in a room of a secret government installation, is an envelope (yes, it is 1000 feet underground). Inside that envelope, written by a steady hand, are three words. These three words when used together are the foundation for effective execution; in fact, without them you are more or less destined to struggle to get things done. For the sake of moving this along, let us say I commissioned the help of an Archer type espionage agent to break in and secure the envelope for us. 

Before we get to those three words I should say sorry* as I bet you were hoping for a nice, neat, reproducible process to optimize your execution. Not yet unfortunately, as we have to start with a foundation to build from. And now for those three words you have been waiting for - "Ownership, Leadership, and The Straw-man" (Ok, technically five words). Worth the wait and hiring a secret agent for don't you think? Given their importance we should look at them: 

OWNERSHIP (very important)  - Defined as the act, state, or right of possessing something. With regard to optimizing execution, identifying an owner is imperative, and I have to stress this, there can only be one. The committee, is the death of effective execution. A single owner, this is key! A single owner:

• Clarifies who is responsible for the expected result(s). Use an actual name. There may not be an "i" in Team but there sure is an "i" in Optimized Execution.

• Optimizes communications with regards to a single voice involving progress, issues and the "go to person" for answers.

• Establishes a champion for teams and resources to rally behind.

• Reduces agendas to one.

• Establishes the owner of the "czar card".**

LEADERSHIP  (table stakes important) - There are a litany of leadership definitions and volumes on the subject, so let's work with this definition for the sake of argument. Leadership has been described as "a process of social influence in which a person can enlist the aid and support of others in the accomplishment of a common task". A couple of comments with regard to effective execution:

• It is imperative that a leader picks the appropriate "Owner"; aligning the task with the needed skill sets and maturity. If you don't have trust*** in the person, don't give them ownership.

• The Leader should clarify the most effective way to manage up to them when issues and roadblocks need to be addressed.

• If the leader has a propensity to micromanage please just stop it; it is annoying and a big waster of time. See trust above.

• The owner needs to be very good at leading without a title, as more often than not they will be moving up, down and laterally through the organization. The book The leader who had no title by Robin Sharma is a must read.

THE STRAW-MAN or Straw-man proposal (Most important) - A straw-man proposal is a "brain stormed" simple draft proposal intended to generate discussion and leadership approval . Here is why this is so important, particularly early on in the process:

• Best developed by the Owner with a small group (i.e. one other person), used as a sounding board to pressure test the proposal. Experience has shown me PowerPoint is a good communication vehicle where you should use strong action statements and high level process maps, as well as foreseeable challenges, resource requirements and timeframes. **** (work to present this within the first week... the sleepless nights are worth it down the road)

• Review the straw-man with the Leader, key stakeholders and anyone you feel may be a resource down the road (in the same room). The objective of this meeting is to review your thinking, so everyone in the room will "sorta remember the meeting" three weeks later. Have any red flags called out for discussion and most importantly have the leader confirm that "directionally" he or she is comfortable with it, and by extension support the detail of the execution.

• It defines the scope and latitude in which the "owner" can operate and where he or she can have to go within the organization to get it done - Gives the owner the answer when someone asks "why are you at this meeting?"

• It becomes the primary communication tool to inform, identify resources needed, re-enforce directional frame work and prevent scope creep (which is another execution killer).

This triad of Ownership, Leadership and The Straw-Man is imperative for effective execution, particularly if the organization is large, where even the simplest act of communication can be a challenge - Let alone working through multiple agendas and business perspectives. I would never suggest this as a silver bullet but I will say it has allowed me to be effective more often than not.

And if it's just you, the discussions are very easy between the Leader and the Owner but I still suggest you use THE STRAW-MAN as you will get your plan down on paper... and we know how important that is. 

gpe.

PS: next time we will talk about the fun that can be had with process maps.

* I'm Canadian so we always say sorry; more often than not though, it is analogous to the word "um" and not an actual apology.

**  A leader I very much admired introduced me to the czar trump card a long time ago . There was a long ongoing discussion where he stepped in and finally said "I rarely exercise the czar card but I am going to throw it and we are going to do it this way...". He was the owner after all and was responsible in the end. For those who don't play cards, a trump card wins over all other cards.

*** The definition of trust is belief that someone or something is reliable, good, honest, effective, etc. 

**** I will admit I am partial to PowerPoint and have made thousands of presentations; I recommend it for a number of reasons 1) lends itself very well to presenting, which you will have to do anyway 2) forces you to be crisp and concise whereas with Word you end up with a white paper and 3) as the project continues the presentations can build upon themselves saving you time.