"Rumble, rumble, rumble. Mutiny, mutiny, mutiny." - Stan Freeburg, 1961

The process map is a documentation of the way that things are currently performed. Not the way that they should be performed, but the way that they are. But quite often, when interviewing process workers to find out how the process works, you'll come across some disgruntled responses. How do you handle these people that are not happy with the way things work? Simple, you ask them more.

The frustrations of the line workers and those involved in the process can come in many forms. The process analyst needs to be able to sort them out, covet the valuable ones, and throw the rest to the parking lot. The value of the complaint comes in a variety of forms. First, and most obviously, the complaint helps you very easily identify the problem areas. The process steps that receive the most complaints need to receive a heavier weighting when considering which problem to tackle. Secondly, many people will follow a complaint (if properly prodded) with a suggestion for how to rectify the problem. These solutions need to be seriously considered and analyzed to see if they have merit and even if they can be instituted quickly and inexpensively (i.e. low hanging fruit). In addition, complaints can point out systems that don't work, handoffs that are unnecessary, delays that need to be documented, and baseline metrics that need to be collected.

The trick is to separate the quality frustrations from the just plain grumpy, bitter complaints. It is important to note that in a traditional, command and control organization, the problems that crop up are all attributed to people problems. The workers are not performing fast enough, the managers aren't good enough, the idea that the problem may be with the process never occurs to them. This blame game is inherently innate in humans, unfortunately, and even in an organization that is moving towards process-centric beliefs, there may still be some blaming going on. It is very important to recognize these grumblings. But don't immediately discount them! Remember that if John's coworkers think he is an idiot, there still may be a possibility that it's John's area of the process or the handoffs in and out of it that need work. Everyone in the organization sees their part of the process, and realistically does not know what John truly does. They naturally equate his steps in the process with him, and if the process breaks down there, it will naturally be his fault. On the flip side, there always is the possibility that John is thick as a post.

The lesson is to not discount the grumblings and complaints of the masses, but to look at them with what Dan Madison calls the "frustration lens." While Madison suggests discounting the person-problem complaints, realize that these might just be process step complaints in sheep's clothing. Finally, don't forget to capture the metrics involved with these complaints. What percentage of the time do these things happen? How many errors happen per week? What is the delay that is seen in this step? These baseline measures are critical to gauging the progress and success of your process improvement project.

The Evolution of Quality Management

 

In his book “Process Mapping, Process Improvement, and Process Management,” Dan Madison talks about the five stages of evolution for the management of an organization. I can’t stress enough the importance of identifying the type of organization that you are dealing with when trying to map, analyze, or improve a process. Where your company or client lies on this continuum will determine not only the approach that you need to take, but your relative odds of success.

 

The first and lowest rung on the evolutionary scale is the control and command organization. This management team knows what’s best for the company and it’s team members and it puts in all of the controls and checks and balances to make sure that it’s carried out that way. This work method lacks the trust and most problems in this company are traced back to a person. The blame game runs rampant and people spend their time covering their backs and trying to fly under the radar.

 

There are many things that these managers need to learn, but first and foremost is that some of their workers have good ideas. Once they realize this and start to even solicit these ideas through the old suggestion box, roundtable discussions, town hall meetings or open door policies, they can move to the next organizational rung. This involvement organization takes advantage of the brainpower of the team. The key is to act upon this input or it will stop very quickly. When moving from a command and control model to an involvement model, management needs to be very supportive, actively demonstrating the new found trust. Team members will be inherently skeptical.

 

The next evolutionary step comes when management comes to the realization that all problems are not people problems. Once the blaming subsides, management begins to realize that the majority of problems lie in the processes being used. This process management style is the third rung on the ladder. This is the organization that will start utilizing process improvement tools like TQM and Six Sigma.

 

Turning the next corner, management appreciates the fact that processes are cross-functional in their nature, and therefore, the process improvements must be cross-functional as well. This company creates process teams to address issues and can undertake true process reengineering projects. Reengineering projects can dramatically improve speed, productivity and competitive advantage.

 

Reengineering and cross-functional process improvement projects lead to next organizational change. In an effort to keep processes and workers from slipping back into their old habits, owners need to be identified for each process. Process ownership provides not only accountability, but increases the cross-functional visibility by changing the metrics that companies use to measure their process and company performance.

 

The final step provides authority to those process owners to fix processes and to allocate resources. This relies on the cross-functional turf wars to disappear and the organization to act more like a team.

 

This progression is not a naturally occurring process that happens to all companies. Management and corporate culture has to accept new ideas and new concepts to move from one stage to the next. So where does your company stand?

 

I remain, as always, your faithful reporter,

 

Paul Gimbel

 

Send me feedback!! (p_gimbel@yahoo.com)

 

Disclaimer: Have you ever seen a movie where the characters were just so way out there that you looked behind you to figure out where in the heck they came from? This is kind of like that. My views came from strange, unknown places, not employers past, present or future or any other human or non-human entity. So stop looking around!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A lot of companies want to improve or even reengineer (a complete overhaul of their core processes), but they lack the internal motivation to make it a priority. How is it that you can get senior management or anyone outside of your department to pay attention?

 

Well step one is for you to understand what is important to the company as a whole, then evaluate if your efforts are in line with those strategic goals. Primarily, you need to understand your company's goals. These are determined by senior management and may or may not be known. I would hope that they are, but you never know. Some companies are after growth (at any cost, unfortunately) while others are interested in market dominance, and others are interested in maintaining a good environment for the workers (ok, these are few and far between).

 

Whether your company focuses on market share, revenues, profits, or growth percentage, the key to all of these is increasing the business coming in the door. And if you can do it at the expense of your competitors, then you're golden. So the primary driver is how to have a key differentiator that will woo clients away from your competitors. Focus on this, then reengineer or improve with this goal in mind.

 

These differentiators often will focus on increased value-add (provide something that your competitors don't), decreased lead time, decreased price, increased quality/Mean Tme Between Failure or Service, longer lifetime, or even a specific function of the product like reduced weight, increased stiffness, faster process time, etc. The key to all of this is that you need to provide some aspect of the product, or more likely, the buying experience that is so great that everyone will flock to your doorstep. All of this has the same purpose, to expand your grip on the market.

 

The other method is to increase revenue by capturing NEW markets. Can your product be modified to appeal to new groups of companies or consumers? Can it be tweaked, or can you create new products that will get you into places and clients that previously wouldn't know who you were? This is a great way to increase revenues, profit and growth, but beware. This method is harder than the previous because new markets can mean new types of clients. Your salespeople may be comfortable selling to engineers, but if you now make them sell to IT professionals, it may be akin to leading lambs to the slaughter. You may know your clients and their needs like the back of your, hey, what's that? Um, sorry. But when you get new clients, you need to gain a new understanding and figure out what drives the new market. Plus, if your company's strategy is market dominance, conquering new markets will simply dilute your focus on that market. In short, you may have to master a whole new class of products.

 

But hey, build a better mousetrap and you'll have dead mice all over the place... or something like that.

 

I remain, as always, your faithful reporter,

Paul Gimbel

 

Disclaimer: When I was a little boy, I dreamt of a column that was mine, all mine, with no influence from anyone like employers past, present, or future. Not like I had employers past or present when I was a little boy. And not like I dreamt of having a column, but hey, don't let the truth get in the way of a good story. Anyway, this is that column. So there!

Last week, we spoke about getting the right metrics. Most managers collect the wrong metrics. Most managers collect what they think they should track because their focus is in the wrong place. Rather than focusing their efforts on improving their department, their process, and their company, they focus on making their boss happy.

 

I know, you're saying, "But that's my job." No, it isn't. If you think that it is, then you need to talk to your manager. You need to discuss with them what is important to the company. Their compensation plan is not your concern. If there's a gap between what you are compensated on, and what needs to be improved about the company, then you need to renegotiate that contract. Performance-based compensation plans can be renegotiated at anytime. And they should be renegotiated everytime the focus changes due to the company, the marketplace, the climate of the groups around you, and so on.

 

Figure out what your group needs to do to increase its value to the company. Figure out how to measure that. Figure out how it impacts the bottom line of the company, then renegotiate to get a piece of those profits. If your manager feels that they can't do it, suggest that they renegotiate their own contract. Pay it forward, so to speak. If your manager just plain won't listen, then get a new job because you're working for a loser. Life is too short to work for losers.

 

Now get out there and keep improving.

 

I remain, as always, your faithful reporter,

 

Paul Gimbel

 

Send me feedback!! p_gimbel@yahoo.com

 

Disclaimer: The content, layout, colors, aromas and sights and sounds of this blog are those of the author only. Except for the smell, that's my son. No credit shall be deemed appropriate for employers past, present and future, because they just don't deserve it! So they can just go ... um, sorry.

Data...UH! What it isn't good for, absolutely nothing, say it again! So this week I've been inspired (as opposed to be expired). Not by a book, or an article, or a speech, but by a question posed by Joe Fleischer (sorry I don't have a linlk to anything for him). He asks, "How can we take data and turn it into information?" Unfortunately for Joe, the rest of the article was pretty worthless to me, but that phrase resounded.

 

Pretty much every system out there collect data, and a lot of managers collect more data. They make pretty graphs and post it on their door (ok, I've been guilty of this). But the data is meaningless unless it's turned into valuable, useful information.

 

The first point to make is that data on its own, without a baseline, is worthless. If I tell you that I weigh...whoa, not going there...ok, um, let's say that I told you that my call center had 53 calls last week. For my current organization that's a lot because the calls can take an hour or more to address. In a former life, that was a day's work because we had more agents and easier issues. Unless you know how many is normal, you can't make information, it's just data.

 

The second point is that you need to collect the correct data to make the right information. Let's stick with the call center example. Pretty much every call center tracks call time. What does call time tell you? How efficient your agents are? How effective they are? I say nay nay! An agent that has record low call times may be rushing the client off the phone, not giving them the right answers, giving incomplete answers, or giving a terrible customer experience. On the other hand, the agent with the long call time may be answering many questions in one call, reducing call volume. They may be spending time with the client answering questions that recommend more products for the client to buy, cross-selling. Then again, they might just be clueless. You just don't know.

 

The final point I want to make today, and yes, there is more on this subject, is that trends are wonderful for trying to predict future performance, it's true. But information can rarely be created from the data of a single variable. If you're trying to optimize the customer experience on your call center, you may need to know when to add a new agent. Do you watch the call volume and make the decision solely based on that? If you do, then you're making a lot of assumptions. You're assuming that the trends are going to continue to go up. Are you looking at large enough of a data set? Are you just seeing a spike due to the time of the year or a new software release? Are you not recognizing that while the current agents are managing the call volume, they're stressed out, not finding the time for education, and putting their resumes on Monster.com?

 

Data is not Information. Information is what data can be turned into with careful and well thought out analysis. Don't let Crystal Reports spit out what you call information. You need to track a baseline, understand all of the variables in the system and collect the right data...then, young manager, one can become one with your data and information will bloom all around you. (Gimme a break, it's Valentine's Day)

 

I remain, as always, your faithful reporter,

 

Paul Gimbel

 

Send me feedback!! p_gimbel@yahoo.com

 

Disclaimer: Once upon a time at an employer far far away, a young sherpa formulated his own ideas. His employers past, present and future, were all unaware as they had nothing to do with the sherpa's thoughts, comments and miscellaneous ramblings. I am pleased to tell you that this sherpa is now a world acclaimed writer. And fortunately, all that stuff (except the world-acclaimed part) applies to me too!

One of the biggest challenges with Process Mapping & Analysis is mapping the current "As-Is" process right off the bat. One problem is that everyone at a company assumes that they know how things work. In reality, though, no matter how in-tune with the company you think you are, in almost every case, you don't know what people really do. You may know what they should be doing, but you don't know what they currently do. This means that the people that actually do the work need to provide the input for what they really do.

 

Another stumbling block is that it is almost impossible for internal people to be fair and objective.  Everyone has their own biases and agendas and no matter how hard you fight them, they subconsiously will filter the information. People will not be open and honest in talking to a co-worker with whom they need to work every day. They'll talk themselves up and make themselves sound more important than they really are. Enter the process consultant. As an impartial third-party, it's a lot easier for us to be objective, and with a little work, we can earn the trust of those that we're interviewing and provide tools to encourage open, brutal honesty. Finally, as experienced interviewers, we're able to better sort out the constructive statements from the bull hockey, as Colonel Potter would say.

 

So the lesson for today, kids, is get an impartial third party to help you do that "As-Is" map. They will illicit input from you and everyone in the group, but they'll be objective enough to provide a clear, accurate map.

 

I remain, as always, your faithful reporter,

 

Paul GImbel

 

 

Disclaimer: This blog represents my objective, ubiased opinion. No agendas from employers past, present, or future have been considered, subconsiously or otherwise in the making of this blog. And no, the microchip implanted in my head was not turned on either.

Anyone that has ever written a program or developed a process plan or designed just about anything uses rules at the center of it. The problem is that most people don’t realize that they are using rules to develop specifications. OK, let’s start basic with what is a rule.

 

Business rules describe aspects of a company’s business that must be true for the company to work. (Paraphrased from Tony Morgan’s Business Rules and Information Systems) The concept is that rules govern the conditions that must exist. Every business rule must be true, otherwise there’s a problem. Business rules should be simple and plentiful. From specifics like “every quotation must be approved by an engineer” to more general things like “every deal must benefit the company.”

 

The idea behind rules is that they are the details that add up to the system. If you’re trying build a house to your local building code, you have a lot of rules. Studs must be no more than 16” apart, for example. But in your building, you also have your own rules. Always use full sheets of sheetrock before cutting. Always use XYZ brand staples. These are sometimes referred to as “rules-of-thumb,” but they are rules nonetheless.

 

But how many companies know what these rules are? Does anyone have them documented? Does anyone hand them to new hires and say “Here ya go, these are all the rules that you’ll need to get your job done.” Nope. And in their defense, it is a big job, and not an easy job, because a lot of these rules are not all that obvious. Many, on the other hand, are so obvious that nobody thinks to mention them.

 

Where this all comes out is if you’re trying to build a process, or automate a process. Automation works by allowing an IT system to build a matrix from the rules and solve that matrix with some given inputs.

 

So get out there and start collecting those rules. Watch this blog for more to come on just how to do that.

 

I remain, as always, your faithful reporter,

Paul Gimbel

 

Send me feedback!!

 

Disclaimer: This blog was presented to you courtesy of the broken brain of the author. No other broken brains were engaged including those of employers past, present, future, or some other dimension of time yet to be discovered.

 

How is your customer service? Great, right? Well, I'm here to tell you that it sucks.

 

Here's the problem that most companies don't realize that they have. What is it that you use to prove that your customer service is first rate? Your call times are short, your customer surveys are positive, your customers give you good testimonials. Big deal. The problem with these methods are that you are measuring the wrong thing. In some cases, call centers measure themselves on throughput, how many calls they can burn through in a day. They measure the amount of time that customers spend on hold. Yes, you're measuring how much you don't suck by minimizing wait time, but that does not equal quality. There are so many more aspects that you don't even know about.

 

What does good, quality, excellent customer service mean? You don't know. You can't know, because it has nothing to do with you and your measurements. Six Sigma talks about the "Voice Of The Customer." This concept tells you that the quality of your service is measured in the customer's eye. And by getting a small smattering of nice responses, you are barely scratching the surface of the problems. You need to actually ENCOURAGE complaints. Complaints tell you what you are not doing right and give you an opportunity to fix those things and win back your irate or simply dissatisfied customers.

 

So what should you be measuring? You need to measure what is important to the client. Collect complaints and measure the improvment on those. Call up and interview the customers that leave to a competitor and find out why. Also measure the success of your customer service in terms of up-selling and cross-selling. Clients that are satisfied buy more. How often do your customer service experiences result in follow-up sales. Are they buying more? Are they buying other things from you? This is the definition of success.

 

Some companies try to measure success in terms of contract renewals. This is only really an accurate measure of success if the client can very easily switch to a competitor. If my cell phone contract expires, and I have to cancel my account, then research competitors, get a new phone, fight to get my number transferred and change my online accounts, I'm going to stick with my current carrier because it's too painful to switch. I may hate my vendor, but it's too hard to change. Once an easy to switch offer comes along, I'm history. In some cases, I don't switch because there may be no competitors in my area. In other cases I renew simply because I like the product. I once worked for a vendor where every client said the same thing, they hate the vendor, but they love the product. The vendor was hugely successful...until a competitor came along that made it easy to switch. Now they're struggling in the marketplace.

 

Listen to the "Voice of the customer." Ask your customers, not just the happy ones, to talk so that you can hear that voice. The data that you currently capture is minimally important at best. The easy to measure parameters are rarely that valuable ones. Get out there and get the hard ones.

 

I remain, as always, your faithful reporter,

Paul Gimbel

 

Click here to Send me feedback!!

 

Disclaimer: Blame me!!  Please!! No vendors have been harmed in the writing of this blog. No employers have been consulted, past, present or future. Blame me!! I could use the press ;)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

So last week we discussed how you can start with the end in mind and work backwards through a value stream map. We said (I hope) that you can take a deliverable and figure out what information is used/needed to create that, and what's needed to create THAT and so on.

 

Something interesting happens when you do this, however. If you focus solely on determining the information required for the current step, then you create more of a SHOULD-BE map, then a true AS-IS map. For example, if I determine that this document requires a cost and a margin, that will require determining a cost from purchasing and a margin from the sales manager, that does not indicate that what really happens is that sales performs a search on how much all of our competitors charge and how much we've charged in the past. Because that step does not directly create value for the next step, it can be very easily overlooked.

 

Another method to map an As-Is process, is to ask and observe those that know. Simply "staple yourself" (Hammer and Champy) to a work unit. Whether that's an order, a new product being developed, an application, whatever, staple yourself to it (figuratively, not literally - see disclaimer) and follow it through the process. Note who it goes to, what they do to it, make copies of any documentation created or referenced, note any system or tool that is used, and note anyone that is contacted in the course of the process. The more hardcore of you might want to bring a clipboard and a stopwatch, but that really makes people nervous.

 

By doing this document and tool/system collection, you can really watch the information that is generated (99% of it is recorded on a form or into a tool/system if it's not immediately consumed) and when it is consumed. This way you can redesign the process/systems to put the right information where it is needed, when it is needed. You can also identify information that is not consumed, is generated at the wrong place/time, or other wasteful activities. Some people like to create a master form that gets routed (maually or electronically) and everyone fills in their portion. This is fine, except sometimes these can become unweildy and humongous, Gargantua the Mega-form.

 

However you choose to do it, just remember that you really need to understsand where you are right now before you start mapping your future. Without a good grasp on the present, you will forget or neglect things that need to be in your process. You won't be able to aggressively evaluate everything that you're doing to see if it's obsolete, unnecessary or just plain stupid. And you won't be able to see when people are slipping back into their old habits. So start mapping!

 

I remain, as always, your faithful reporter,

Paul Gimbel

 

 

Disclaimer - The author shall be deemed harmless and free of responsibility for any incidents involving people stapling themselves. If you staple yourself, you deserve it! And in turn, the author shall take responsibility for all of the viewpoints, witicisms, and other great things in this article. No credit (or blame) should go to employers past/present/future or any other entity, real or fictitious. Unless they're a bunch of snot-nosed kids, in which case, you can hold them liable for anything bad.

In taking a look at processes, a lot of people simply try to run through in their mind, "OK, what are the steps." But mapping a process is actually more difficult than that. If you just ask someone to sit down and write out what they do, they'll almost always forget things, leave out key details, put things that they SHOULD do, instead of what they do, and so on.

 

But the key to having a successful process map actually lies in one of Covey's 7 (now 8) Habits, BEGIN WITH THE END IN MIND. Start by looking at the end customer of your process, and then consider what the deliverables are to that customer, then work backwards, asking "What information or action is required to generate that step? What are the inputs required to produce that output." This will give you a complete picture of all of the steps REQUIRED to create your deliverable.

 

One interesting note, though. Value Stream Mapping people like to use this technique. They say that looking at it backwards makes you think more. And it does, just try saying the alphabet backwards and pay attention to how much more concentration it takes to saying (or singing it) forwards. The problem is that what you get out are the steps required to generate the deliverables. You do not get the unnecessary steps, the muda or waste, that Lean Analysis is looking for.

 

There are eight categories of waste, and three types of waste according to Womack and Jones (Lean Thinking) and among those three are activities that are wasteful and unnecessary. There's a good possibility that these activities will not surface in a reverse analysis. The solution most commonly used is to review the process forwards at the end of the day, but most people just want to agree so that they can go home at this point.

 

So be careful when you're evaluating and mapping your processes. Make sure that you can account for every minute of your day. A great technique here is to figure out what percentage of your day you spend doing each activiity. This is very helpful because it lets you figure out where to focus your efforts, helps you understand where your waste is, provides valuable metrics, and ensures that you don't leave anything out.

 

I remain, as always, your faithful reporter,

Paul Gimbel

 

 

Disclaimer: This wonderfully created colonial bedroom set of ideas are the results of the mental craftsmanship of Paul Gimbel. Anyone else claiming responsibility "is just itchin' for a fight."

Of course you hate your new software, it's not what you're used to. And yes, you can get your work done faster the old way.

 

Wait a minute. Am I in the wrong blog? Are you actually saying that my old software is a better solution!?!?

 

ABSOLUTELY not. I am simply confirming you current stage of grief. Yes, there are stages of grief in the implementation of a new technology tool, much like there are in any ofther grieving process. We've seen this happen at almost 100% of the companies that we've served, so don't think that you're going to be different. Now the five stages in implementation are different from the Denial, Anger, Bargaining, Depression and Acceptance Elisabeth Kubler-Ross came up with in 1969, but let's look at some parallels.

 

DENIAL - At first there are two types of people. We have the thoroughly excited folks that saw the demo, or went through the training and now see the light. They have the vision and they truly believe, for now, that this new tool will revolutionize their jobs. The other group are the grumps that fear the new tool. This can be for a variety of reasons from a simple resistance to change, resentment over not being included in the decision, fear of losing their place in the corporate society pecking order ("I was the XXX expert, now we all know the same"), or a variety of other reasons. NOTICE that all of these reasons were PERSONAL, EMOTIONAL reasons. Externally, they will be in denial, telling people that the tool is not a good fit, it doesn't do what we need it to do, it's not going to work.

 

ANGER - The anger comes in when the consultant leaves after the implementation. The training is done, now people have to fend for themselves. They're still newbies with the new tool, so when they forget how to do something, or can't figure something out, they get angry. Of course, this anger and frustration is misdirected and people start to hate the tool. In most cases, it's simply a training issue, meaning that further training would resolve it. In other cases it's a setting or a change to the tool that needs to be made. And yes, while you are learning to use the new tool, you WILL be slower than you were before. That's always supposed to be factored into the project.

 

BARGAINING - "But I can't get this job out to the shop floor in time if I use the new system. Just this once, I'll go back and use the old system, just to get this rush order through, then I'll go back to the new system." Yeah right. That never works for "just one bite of cake" or "only three cookies" so what makes you think it's going to work here? People make these deals with themselves, and when they step away from the new tool, they lose more and more of the training which makes them slower and less and less effective each time they go back to the old way.

 

DEPRESSION - Depression sets in when people realize that they're never going to be able to use the new tool. Even those that were gung ho at the beginning start to falter and wane in their enthusiasm. Why? Because they find so many "holes" and "bugs" and other things that just make it the wrong tool. In most cases, it's just a training or implementation issue. But since this depression is starting to set in, the users only complain to each other, not even giving the implementer a chance to show that it really CAN do all of the things that they want.

 

ACCEPTANCE - At the final stage, it's either pass or fail. If the complaints are addressed, and the tool is customized, or a consultant comes in to work with people to help them get through real life issues, then people will be happy with the tool and will pick up the flag and continue growing the tool on their own. If the complaints are not addressed, and the din of groans and whining reaches the top-management, then they will accept the fact that the tool was a failure and they'll pull the plug to cut their losses.

 

How can you guarantee a passing grade? For starters, get the top management in the company behind the movement. They need to be consistently vocal and active. They need to provide the resources - human, financial and otherwise - to show their support. That will trickle down to your boss, who will make everyone understand how important it is. Secondly, they must let people know that this is how we work now. And "if you don't like it, let me know so I can replace you." It sounds rough I know. But reread this entry and you can see that only one or two people that have PERSONAL issues, can derail an entire department and the entire company. These cancers need to be removed, surgically if necessary. Finally, the users need to voice their concerns to the implementer and GIVE THEM A CHANCE TO ADDRESS THOSE CONCERNS!! The odds are that nobody has brought up this issue yet. The tool can handle it, but the implementer never knew to set it up that way, or to teach you how.

 

So stop grieving and live!

 

I remain, as always, your faithful reporter,

 

Paul Gimbel

 

Disclaimer: These thoughts and opinions are mine, not my employers' past, present and future; not my dog Scruffy's; not my stuffed bunny Mr. FooFoo's. GOT IT!?!?

Having about 10 years of experience in the software demonstration vocation, I've developed one big pet peeve about presentations and demonstrations in particular. The focus of any presentation MUST be the audience. PERIOD.

 

Far too many of my peers - and yes, I'll admit I did this at first - will showcase their product, idea, or work in the presentation. The presentation is not about you, your product, or what you did over the last month or over your summer vacation. The presentation is about what all of this means to the audience. The topic is not "My Message" it's "What My Message Will Do For You and How Your Life Will Be So Much More Worth Living Once You Have My Message." Now a little disclaimer here, you might not want to put that on your title slide. Then again, you might, I don't know your audience.

 

Do YOU know your audience? Software salespeople are fond of using a product demonstration as a way to meet the prospect. Service providers use a presentation to introduce themselves. Now I'm not opinionated, but that is WRONG! If you're just going through your shpiel spitting out facts, features, charts, figures, you're putting them to sleep. You're asking THEM to sort through the detritus to find anything that might be helpful. And then you're throwing so much at them so fast that you don't give them time to think. You need to know your audience and know what's important to them before you walk into that conference room. Then you need to customize your message for them.

 

NOOOOOOOOOOOOO! The dreaded words, "CUSTOM DEMO!!" No, that's not what I said. I didn't say customize the presentation (although that would be nice). I said customize the MESSAGE. Thi