Six Steps to Solving Problems Proactively

I'm on a plane from Chicago back to Seattle.  Internet on the plane - amazing.  I was out for a just a single night so I could present at the UBM Canon ASQ Quality Expo at McCormick Place.  Just enough time for breakfast at my favorite diner (11 City Diner, 11th and Wabash) and a jumbo Chicago dog at the stand across from the Alaska Airlines gate.  The topic was "Solving Supply Chain Problems Proactively".  Apollo President Chris Eckert and I presented this same topic this year at the ASQ World Conference on Quality and Improvement in Pittsburgh, PA a few months ago.  I never miss a chance to go to Chicago - one of my favorite cities - even if it's only for a day.

We like to take the opportunity to show root cause analysis as a proactive tool.  Most people think that RCA is purely reactive, meaning that it's only any good once something bad has happened.  There's some truth to it - we generally apply RCA to events that have already occurred.  In that sense, one of the primary outcomes is to identify corrective actions.  Corrective actions fix known errors.  But what about preventive actions - those actions that help reduce the risk of potential future problems from occurring?  That would be a great proactive outcome of an RCA.  Yet many people don't do this - and I'm not sure why not.  It's not that difficult.  Let me see if I can walk you through six simple steps in a few hundred words...

Step One:  Identify KPI's
KPI's are Key Process Indices.  (FYI:  I'm not too proud to link to Wikipedia for this blog.  If you want to do more research, use the links at the bottom of the Wikipedia page.)  Every company has KPI's.  Examples include specification of tolerances, delivery times, scrap, downtime, and any other measurement of performance you can think of.  KPI's derive from goals and objectives.  Identify the primary KPI's for your business.  You'll need them in the next step.

Step Two:  Identify Problem Triggers
Problem triggers are significant deviations from your KPI's.  When a deviation is significant, it should trigger a root cause analysis.  You need to define these triggers, but be careful.  Most set their thresholds too low, which trigger more investigations than they are able to adequately complete.  This leads to suboptimal results.  Be conservative at first, and then tighten thresholds down once you are sure your team has the capability to keep up with the investigations they trigger.

Step Three:  Perform RCA
An organization needs to commit to a single RCA process, and they need to do it well.  If you aren't sure which process is best, give us a call... we'll help you sort it out.  But a single RCA methodology is crucial to success.  Everyone needs to speak the same language.  The notion that people can use whatever they want as long as it works for them is detrimental to the program.  Make a commitment!  Evaluate what's out there and commit to one process.  And if you're serious about it, you'll realize that the 5 Whys and Fishbone are completely outclassed by several modern RCA options, of which Apollo is one.  Things change for the better over time, and RCA is no different. 

Step Four:  Identify Systemic Risks
This is where the real proactive opportunities are found.  Most analyses will lead to systemic causes, but only if they go far enough.  These are causes that are actually part of the system itself.  They have been a cause of problems in the past, and will likely be a cause of problems in the future.  Finding and eliminating these causes is truly more "preventive" than "corrective".  And they can be found in almost any root cause analysis - as long as the investigator goes far enough and knows what to look for.  Common cause analysis is a great way to identify systemic risks.

Step Five:  Share with Others
Many companies simply don't take reporting seriously.  Think I'm wrong?  Pull some of your incident reports and review them critically.  Do they tell you what the problem was, when it happened, where it happened, and what the significance of the problem was?  Do they tell you the causes of the problem?  Do they contain a detailed cause summary?  Do they provide you with evidence for the causes?  And do they identify solutions that directly impact those causes?  These are just the basics, but if you've answered yes to all of them then your company stands apart from most.  We need to share what we've learned so that others can benefit from our efforts.  This leads to true organizational learning.

Step Six:  Scale Up!
Once you've proven that you can make this work on a smaller scale, it's not difficult to step it up a notch or two. 

That's 550 words including with headers.  I could probably shrink it, but we're landing soon... time to power down...

The Floating Drishti

I bargained my way into a beginner's yoga series a few years ago.  I would attend 1 month of beginning yoga, and my girlfriend Kathy would go mountain biking with me five times.  This is what is called a win-win scenario in relationship management in that we each learn an activity that the other loves while getting to spend time with each other.  This was perfect for me, since it was February (in Seattle) and not exactly the best month for biking - so I stepped up first.

One of the first things we learned was to choose a drishti, which is a Sanskrit term meaning "focal point".  In my layman's understanding, this basically meant that I'd better find one spot to keep my eyes focused on or else I'd completely lose my balance and fall into a twisted pile of human spaghetti.  It was helpful - and in moments of complete agony as muscles and tendons stretched into positions invented by some maniacal Twister overlord (read 'crow pose', or 'Bakasana'), the drishti provided me with a trail of breadcrumbs back to the world as I had left it.  At the time I associated it with hope, albeit dim. 

As I became more adept at the poses over time, I realized that maintaining the drishti was actually critical to ensuring proper form and balance.  As my eyes focused on the spot, my practice also became more focused.  For certain balancing poses, that focus actually became like another limb that I could rely on to support me. 

Later, while mountain biking, I realized that I use the same concept of a drishti to successfully navigate technical trail features.  Novice mountain bikers crash a lot.  This is often because they are looking at the trail immediately in front of their front tire.  The novice focuses on what he/she wants to avoid - rather than on where to ride.  They exist in a purely reactive mode.   By the time a problem appears, they've left themselves very little time to choose and then execute a successful solution.  How do I know this?  I'll post a picture of my shins sometime - each scar represents a lesson.

Looking down Double Black Diamond, Chuckanut Mountain, Bellingham WA

As I progressed along my personal learning curve, I learned to look a little further down the trail.  This allowed me to stop reacting to trail problems and start anticipating them.  By the time my tires actually reach the problem, it's usually been solved proactively leaving only the execution of the maneuver.  At the time of execution, my focus has moved on to the next problem.  It wasn't until I was exposed to yoga that I actually had a word for this focal point - the drishti.  The difference between a drishti in yoga and a drishti in mountain biking is that mountain biking takes place while moving through space, while yoga generally takes place in a fixed position.  So the mountain bike drishti continually floats in front of you.  It's a relative reference point versus one that is absolute.

This concept works for me on long slogs up logging roads, technical trail climbing, as well as for risky descents down slippery, rocky, root-covered terrain.  The drishti point represents the perfect balance between planning and execution, the point where supply meets demand, the point where upstream and downstream processes are in harmony with their bottlenecks.  This is why I love mountain biking so much.  You place yourself in a position where the world melts away to a single point, constantly changing, floating approximately three feet in front of your tire.  To experience the perfect balance between breath, strength, risk, focus, and execution is nothing short of blissful.

I don't win everyday at work, but those days I do come out on top are very similar to what I described above.  The work drishti is more abstract than in yoga or mountain biking.  I won't physically fall over into my sweaty neighbor or maul my shin on a sharp boulder if I lose my focus at work.  The stakes are actually much higher.  Identifying and maintaining an effective drishti is a primary cause of success in anything we do.  

Designed by Apple in California, Fatalities and Production Delays by Foxconn in China?

Last week I traveled to Pittsburgh with Chris Eckert (Apollo President) to give a presentation titled "Solving Supply Chain Problems Proactively" at the ASQ World Conference on Quality.  We didn't have a packed house, but it was nice to see approximately 75 attendees, especially on the day after the exhibit hall closed down.  Our presentation  discussed how the supply chain benefits when different links in the chain team up to solve problems.  It was a timely discussion in light of the global supply chain problems experienced since the tsunami in Japan dramatically delayed production and delivery of critical components.  The risks of sourcing globally are difficult to estimate - particularly when taking natural disasters (and their man-made multipliers, ie Fukushima) into account.  Add in the trend towards leaning out inventories, caused by the need to demonstrate to investors and analysts that a company is not tying up cash needlessly (you can think of it as 'just in time' rather than 'just in case', which I can't take credit for coining) and you can see just how vulnerable the supply chain really is.  It makes me wonder if companies that have proven to be most vulnerable to supply chain disruptions post-tsunami have robust root cause analysis/problem management processes in place.  If so, did these systems uncover proactive opportunities to identify and mitigate the risks of such disruptions?  It would be an interesting comparison.

Today, I read an article about how a dust explosion at the Foxconn factory in Chengdu, China was threatening to delay delivery of Apple's latest iPad 2.  This is actually what prompted me to write - I owed an entry regarding ASQ last week and this was the perfect prompt.  I actually knew just a bit about Foxconn and the iPad, but only as much as one can learn by attending the one man act "The Agony and Ecstasy of Steve Jobs", a monologue by Mike Daisey currently playing here in Seattle at the Rep.  It describes the author/actor's obsession with all things Apple and his discovery that these little nuggets of technical perfection are actually created by humans.  I learned (if Daisey can be believed) that the Foxconn factory Shenzhen, Guangdong Province of China, employs 250,000 people.  They have 10 cafeterias that each seat 25,000.  They don't just make iPads or iPhones, but electronics for many different companies.  This is a little different than big factories I've visited here in the States.  I've been to the Boeing plant in Everett, WA many times.  It's the largest enclosed space in the world (click the link above to see it - Boeing has a great aerial shot on their website and it's amazing).  They make all the wide-bodied Boeing planes there.  And they employee nothing close to 250,000 workers.  Foxconn's huge factories are the physical manifestation of the global supply chain at work. 

Back to the story.  The iPad 2 is selling like gangbusters.  I wanted to buy one for my Dad, but found out that I'd have to line up at 6:00am or earlier if I wanted one.  I got him a jacket instead (Adam Smith's invisible hand?).  What could be worse for Apple than a delay in delivery at this crucial time?

Apple may design their products in California, but they manufacture products in China to take advantage of state of the art production facilities and cheap labor.  Basically, the savings more than offset the cost of transportation.  By concentrating production with Foxconn in two facilities, they can reduce costs by negotiating more favorable production prices.  However, they also take on more risk by placing their eggs in a single basket.  Add in lean inventories (due to demand, management, or both) and a disruption could cause Apple to delay sales, which could in turn cool the public's interest in the new iPad prematurely.  Millions of dollars are at stake.  But that's not all.  One quote from the story stood out...

"There probably is going to be no impact" if production resumes as expected in the next few days, said Citigroup analyst Kevin Chang in Taipei. "If this safety inspection drags on for two or three weeks, then there will be an impact on production." 

Did I mention that the article reported that 3 people were killed and 15 were injured in this dust explosion?  We teach in class that there is no such thing as a "safety" problem, a "quality" problem, or a "supply chain" problem.  There are problems which impact various goals of an organization - but problems themselves don't respect our carefully defined boundaries.  Kevin Chang of Citigroup seems to think that Foxconn's biggest problem is making sure that investigators pencil-whip up a safety report asap, because if not there may be an impact on production.

Is it just me, or does it seem like Kevin Chang isn't getting the bigger picture?  It's not just a safety problem, Kevin.  But the fact that this explosion had a - how to say it - negative impact on Foxconn's safety goals did bring the problem to light.  Now I'd be speculating if I were to start listing out causes of the dust explosion.  And I'd also be speculating if I were to say that the safety standards in Chinese factories are woefully low compared to factories here in the USA.  But I'm not speculating when I say that there are very often precursors to a catastrophe such as this.  A mature root cause analysis/problem management program would likely have identified these precursors and provided Foxconn with an opportunity to reduce these risks before they manifested into this outcome, which had both a safety impact as well as a production impact.

I'll get to the point.  Companies that outsource often make the mistake of thinking they've outsourced the risks along with the work, but that's not true.  I'm no protectionist...I'm a proponent of "whatever-makes-the-most-sense sourcing".  But however you decide to set up the supply chain, you will maximize returns by implementing a common problem management effort that transcends organizational boundaries.  That means Apple ought to be involved in this investigation, just as if the explosion occurred at One Infinite Loop, Cupertino CA.  Hopefully that's the case...

Newest Sleep Aid: Controlling Aircraft After Midnight

There's a lot of talk about air traffic controllers falling asleep on the job these days.  First at Reagan in Washington DC, then apparently at other airports - including Reno and Boeing Field here in Seattle.  In each case, the dozing employee was suspended.  And today, we find out that the Chief Operating Officer of Air Traffic Organization Hank Krakowski has resigned from his post.  FAA Administrator Randy Babbitt had this to say:

"Over the last few weeks, we have seen examples of unprofessional conduct on the part of a few individuals that have rightly caused the traveling public to question our ability to ensure their safety.  This conduct must stop immediately."

The FAA is also adding air traffic controllers to midnight shifts at 27 towers in different cities around the US.  But as a frequent flyer, I have to ask myself if I feel safer as a result of these actions and tough rhetoric.  Any of you who have been through our root cause analysis training know that disciplinary action employed as a solution strategy raises red flags because it is seldom effective at actually reducing risk.  Were errors made in these cases?  Undoubtedly - but it doesn't take a professional investigator to figure that out.

I'm a fan of James Reason and his approach to understanding and managing human error.  While I don't subscribe to his categorization model for accidents, I do find his analysis of how errors come to pass very useful.  My understanding of it goes like this:

You can't commit an error without intent.  In other words, you need to have intent as a motivator for your actions in order to commit an error - otherwise it's just an involuntary response.  Drooling on your pillow while sleeping, for example, is not an error because there was no prior intent.  In this case, the air traffic controllers did have an intention - which was to safely manage the air traffic in the airspace for which they were responsible.

The next question is whether the actions proceeded as planned.  From the articles I've read, it would appear that in most of these cases, the answer to this would be no - the air traffic controllers did not plan to fall asleep on the job.  One exception to this was in Knoxville TN  where the controller apparently made a bed on the floor of the control tower out of pillows and slept for 5 hours.  That's another story, but one that likely still shares many causes.

When actions proceed as planned, and they achieve the desired results, then there's no problem.   In fact - this is what happens most of the time.  But in the case of the air traffic controllers, we see that this wasn't the case.  So now what?

Reason has developed a decision tree to assess culpability, which can be found in it's original form on page 209 of his book Managing the Risks of Organizational Accidents.  There are various customized forms of this model, but they each subject the error to a series of tests to determine whether disciplinary action would effectively reduce the risk of recurrence.  The following is based on a modified version of Reason's decision tree.

First is the Deliberate Harm test.  Were the actions intended to cause harm?  If so, then disciplinary action is absolutely appropriate.  Did the air traffic controllers intend deliberate harm?  I think the answer is no - not in any of the cases.

The next is the Health test, which examines whether there were underlying medical conditions that resulted in the error.  I would say that the air traffic controllers were not fit for duty due to the fact that they could not stay awake during their shifts.  Therefore disciplinary action is not likely to be an effective solution strategy.  Effective solutions are effective only because they control one or more causes of the problem.  And I don't think you can control a health problem with punishment. 

The next test examines the Procedures that govern behavior.  Did the employee violate established procedures?  And if so, were the procedures clear, correct, safe, and being followed by others?  In the case of the air traffic controllers, I think the answer to the first part of this test is yes - each of them violated established rules against sleeping on shift.  The second part of the test though is harder to answer accurately without in-depth analysis and interviews, particularly whether or not the procedures were being followed by others.  I suspect these procedures were violated as a matter of course, although I can't back it up.

The final test examines whether or not someone with similar training/position would have likely acted in the same way in a similar situation.  Given the fact that so many instances have come to light, I think the answer to this question is yes - they have acted in a similar fashion in the past, and will likely do so again in the future if no changes are made.

Last night I saw a segment on the PBS News Hour that included Alan Levin, who covers aviation for USA Today.  In this interview, and in his April 14, 2011 article in USA Today, Levin discusses systemic fatigue as a problem throughout the air traffic control group at the FAA.  The FAA has apparently known about this problem for some time now, according to this article.  That shouldn't be news to anyone familiar with the patterns of undesirable events.  For every incident that comes to light, there are several that no one found out about.  I think it's safe to say that air traffic controllers frequently fall asleep on the job during this midnight shift and that they don't post it as a status update on their Facebook page:

In the News Hour interview, Levin goes on to discuss how structured napping has been proven to help alleviate fatigue but that no one will propose this as a solution because it won't pass the "Jay Leno" test... in other words, it would be ridiculed non-stop by late night comedians as well as politicians.

At the end of the day, this drama shows just how far we have to go with respect to managing human error.  The solutions proposed include the resignation of a high level manager, the suspension and likely dismissal of 6 air traffic controllers, and the expressed outrage of FAA Administrator Randy Babbitt.  I hope they don't stop here, but if the story dies that's likely going to happen.

Whew... I feel like they've really gotten to the bottom of this one.

An updated article from the Seattle Times... worth reading if you have a few minutes...
Another updated article... the hits keep coming!

What kind of rider are you?

It's Sunday morning... 6:30am. I've been up for an hour drinking coffee, eating breakfast, and scanning headlines. In a while, I'll dress myself in weather-appropriate biking gear and head out to meet friends for a 70 mile road ride in the rain. It's not everyone's idea of a perfect Sunday morning - I'll admit. But I'm a happier, more rounded person if I can burn off a few thousand calories several times a week. That means the people in my life find it easier to be around me... me included.

Sometimes the weather here in Seattle is less than ideal. That's because it really does rain here. October through June are generally wet months. What's a rider to do? Head indoors, of course. I belong to a gym that offers spin classes. In years past, I didn't have a lot of respect for the spinners. Why belong to a gym when you can just ride your bike? Duh! But after some prompting by my significant other ("You are driving me nuts, and not in a good way. Please, join a gym.") during an extended period off the bike due to weather, I tried it out. That first hour of spin class was one of the hardest hours of my life. Thoroughly humbled, I hobbled back home, grateful that I could train in a meaningful way indoors during the bad months.

I settled into a routine... spinning at least twice a week, and riding my bike as often as possible. What a great combo. But what became apparent to me was that the two groups of riders - spinners and cyclists - generally don't interact that much. Many cyclists never set foot in a spin class. And many spinners would feel extremely awkward clipping into a bicycle. In fact, there are even terms to help delineate the two activities - riding "outside" and "inside". "Do you ride outside?" my instructor/tormentor asked. I found out that she was exclusively an inside rider.

So what does this have to do with root cause analysis, you may ask?

When Apollo hosts training classes, attendees are "riding inside". The instructor has a lesson plan, manual, and example exercises. He/she fits the course regimen to the individual characteristics of each class. Investigation and analysis are simulated. It's a challenging class. But it's fun too - and students get a lot of value out of being challenged in the "inside" setting. It's also safe. There are no cars, potholes, slippery roads, jerky drivers, slippery manhole covers, drunk UFC fans (seriously)... nothing that will cause you physical harm. Root cause investigators put themselves at risk in the real world. They are held out to be experts. Their work is visible and often of great interest to the organization. But not while in the classroom... that's an intentionally safe environment.

But training is not just for fun. Once class is over, it's time to go to put your skills to work outside. Many RCA Facilitators find their first real investigation to be uncomfortable. This is because they are juggling two new and challenging tasks at once - analyzing a problem with a new methodology and facilitating a group of diverse, often skeptical, experts. Add to that the fact that many times people wait several weeks before putting their new skills to work... not a good idea. The skills you pick up in training have a half-life as does your confidence in those skills. Many attendees find out the hard way that they don't match up. Confidence remains high longer than the skills remain sharp.

To get the most out of root cause analysis training, we recommend you get started "riding outside" as soon as possible after class. No excuses - just do it (where have I heard that before?). What are you waiting for? A catastrophe? Believe me, that's no time to start.

Begin easy - don't put yourself at too much risk. Pick something simple, something that can be completed in a few hours. And then do it again at least two more times as soon as possible after class. This consolidates what you learned inside. You will effectively bridge the gap between the simulated class environment and the real-world investigative process. Involving others from your training will help. Take turns leading and offer helpful critique. And get your Apollo instructor involved - he/she will be more than happy to offer advice.

@brian_hughes

Killng the concept of the 'cost center'

In my last post, I mentioned how my experience at the 2011 Pink Elephant (#pink11) conference in Las Vegas at the end of February reconfigured my understanding of the power of social media. After seeing my last entry retweeted 5 or 6 times, and picking up a few followers in the process, I think the conversion process is complete. So let the refining begin...

What I'd like to discuss today is the concept of the "Cost Center". As a root cause analysis consultant, most of our clients are considered to be overhead - Safety, Quality, Reliability, IT, Supply Chain, etc. We don't get a lot of sales/marketing people in our seminars. That's because the benefits of our products/services are often cast in the paradigm of future cost avoidance. "If we could just find the root cause of this problem, we could avoid all this in the future..." You get it.

As cost centers, someone somewhere (McKinsey? Accenture/Anderson? Tom Peters? Whoever it was, thanks...) came up with the concept that these cost centers need to consider themselves as blue-dollar revenue centers with customers, sales, expenses, etc. Their competition? Any market alternative. In other words, if a training department provides the service of identifying training needs and providers, negotiates pricing, provides facilities, conducts scheduling, and keeps track of records, then they need to do this at a price that is competitive. If some outside firm can provide equal or better services at a better price, then the internal training department is potentially at risk of being outsourced. The beauty and simplicity of the invisible hand at work... what could be more '90's than that?

Heck - I've bought into that concept since the first time I heard it. And I still do, but it's been modified by an experience I had at the Pink conference where I was fortunate enough to select a professional development session let by a man named Dr. George Westerman. Dr. Westerman is a research scientist at the MIT Center for Digital Business. His presentation stood out because a) I saw him last year, and he was great, and b) his topic was the value an IT organization brings to the business. He has a new book out on the subject "The Real Business of IT: How CIO's Create and Communicate Value" (written along with Richard Hunter, who is Vice President and Gartner Fellow at Gartner) which I'm still reading. But I'm incorporating the concepts with clients in two different ways already, and having some success. I think these guys are on to something that will impact both sales and service at Apollo, but also is relevant to the leadership of any "cost center".

Cost centers are seen as detrimental to the bottom line. The natural inclination is to reduce the cost of the cost center. Hence downward pressure on budgets, do more with less, maximize efficiencies, hiring freezes, and oh yeah - don't let service levels slip. But what if this thinking is wrong and the opposite were true? What if cost centers were critical to achieving bottom line goals? That would make them investment centers - a much more palatable label in my book. But if this is true, then managers need to change their thinking about exactly what value they bring to the party.

Step one in Hunter/Westerman's book is to change your thinking to avoid what they call "value traps". A value trap, as I understand it, is an inward focus on the metrics of the department rather than on the metrics of the business itself. In other words, maximizing critical asset uptime is a metric that maintenance/reliability people love to track. And in their world, it's important. But ask an account manager if he/she has ever even heard the term, let alone what it means to the overall goals of the business. Sure - everyone knows that if the critical machine stops stamping out widgets, no one's going to get paid. But if you focus on uptime and stop short of relating it directly to bottom line revenue for the period, you're stuck in a value trap. You're only a cost at that point - not an investment. And as a cost, you've only got downward pressure.

That actually leads to the second point of the book... show that your department provides value for the money. You've got to do the math and show it. Don't know how to do this? That's okay - there's a department called "Finance" that does. Get them involved - their third party assessment of the return on investment in reliability for the period will be more credible with others in the business anyway. These should be the metrics you share with the world and that drive your department - not uptime or other "machine" type metrics. Show the cost side as well... by showing the basis of the investment as well as it's return, you'll show exactly how your efforts have impacted the bottom line - not just the cost. Here's an analogy. A lineman in the NFL reports to a coach the time he's spent in the weight room, the miles he's run, and the films he's studied to show what he's doing for the team. If this is all he's doing, he's hosed. The coach (and fan base) cares about the key blocks he's made, the yards gained from those blocks, the number of sacks that come from his area versus others, etc. Align your metrics with bottom line performance.

So now that you've changed your focus from cost to investment, and you can actually report metrics showing your impact over time, now you need to improve your performance. Set achievable goals to move these metrics in the right direction. At this point, you're no longer managing the IT department, or the Human Resources Department - you're managing business performance. This has a bottom line impact - not merely a reduction in blue-dollar cost.

Finally, once you've moved through the three steps above, you can actually shape the direction of the business itself. Imagine that - a cost center leader having a direct impact on the future of the business.

Well, you kind of have to imagine it because it doesn't happen often. But these concepts struck bedrock with me. I'm always trying to get people to look at root cause analysis/problem management as an investment. Spend X on investigation/training and you'll get your money back as a reduction in future risk as your return. And they nod their heads in agreement in class when we discuss it... everyone agrees, at least while they are in class.

But when reviewing analyses, I'm often astounded that people don't do what they agreed was a good idea in class. They often shortchange documenting the significance of the problem. Well, this is a value trap. The value the investigation provides doesn't stop at solving the problem. The value carries forward to the bottom line for the period. And if you can't or won't calculate it, you're selling yourself short. The business can only pat you on the shoulder and tell you to reduce your budget by 15% next year.

I mentioned at the beginning of this entry that I had incorporated this with customers in two ways.

First Way: Sales
Do I want people to budget for Apollo training, or invest in a root cause analysis/problem management program? Sure - both lead to sales for us, and I'm not too picky. But if I had my way, I'd much rather they consider money spent with Apollo as an investment with real future returns. So I change the conversation right away. It's not hard to get a prospect to see a commitment to Apollo as an investment. The hard part is asking them how they would measure the return which leads to the second way I'm incorporating this concept...

Second Way:
Knowing that they think of themselves as line items in a budget and not investments, I've first got to get them to see themselves as critical to achieving bottom line periodic business goals - as critical as any other department. What causes net income? Sales, or Human Resources? Sell all you want, but remember that one of the things you're selling is your staff. You've got to have both to be successful. Getting Safety, Reliability, Quality, and IT to recognize that they have real, measurable bottom line impact is critical. If money spent on Apollo is an investment, then by extension money spent on Safety is too. That's a powerful thought to those in the cost-center value trap.

I had my first success last week with a utility client. I had the pleasure of working with a new director of HR and her staff. They graciously let me fumble my way through explaining these new concepts. But I could see the light really come on when we distilled it down to this simple statement:

"The goals of this utility are to keep the lights and power on, and to do it at reasonable rates. There is no difference between the goals of the utility and the goals of the human resources department - you need to think of yourselves as keeping the lights on, the gas flowing, and the rates reasonable."

As their RCA/Problem Management consultant - those are my goals too...

Brian's Intro to Social Media

Honestly, I can say that I never really got it. Social Media to me has always meant Facebook. Twitter? Nein danke. I couldn't understand why I'd like to 'follow' people. I was already getting status updates from friends on FB... why would I need to get the same info from Twitter? It just seemed redundant. But that notion was upended for me this week - hence this blog entry (and hence this blog, period).

We have blogged periodically at Apollo. When I say Apollo, I guess that presumes you know what I'm talking about. Just in case you don't - Apollo is our company (Apollo Associated Services, LLC) and our focus is root cause analysis - a form of structured problem solving. So we're good at problem solving. But apparently our blog wasn't set up correctly, meaning that it wasn't easily accessible to the world. That's a problem, which we solved by simply stopping blogging while we work out the technical stuff. Blogger offers a simple solution that gets our blog off the ground immediately, so here I am... blogging.

We attended the Pink Elephant conference at the Bellagio in Las Vegas this week. Pink supplies ITIL training and consulting, and puts on a seriously awesome conference. They make a bigger bang with 1,600 attendees than I've seen at conferences 10x the size. There is a lot to discuss... but I'd like to focus on my social media epiphany first, saving the other stuff for later entries.
So we're sitting in the general session on Tuesday morning listening to the keynote speaker Captain Michael Abrashoff and David Ratcliffe (Pink Elephant President) mentioned that we could submit questions via Twitter.

I popped open my laptop and went to Twitter. I have actually had a Twitter account for about 3 years or so... when I opened it up, thankfully my computer remembered my username and password. This is the truth - I did not know what I was looking at. So I opened the help file and quickly read it. I learned about hash tags (#Pink11 in this case) and submitted my question.

And there it was...

My first thought was "crap, my picture sucks!". So I changed it out quickly... just in case the question was selected. As I watched the other tweets come in, I started to get more comfy with what I was seeing. And soon enough, what I was seeing was David posting a question from a different attendee on the huge screens on either side of the stage. And once that question was answered, I saw my own question (and picture) posted up in front of the entire group.

Amazing.

It only took a minute to open my computer and thumb my way through my first professional tweet. And then it was projected wide and high for all to see. The question and subsequent discussion took up at least 10 minutes of the presentation. Since I was there to promote Apollo, what better way to do it than that? Of course, the shameless promoter side of my personality kicked my humble side's ass for not including my booth number or company name, but I'm over it now... no reason to be greedy.

As I continued to scan the tweets under #Pink11, I also saw the downside of compulsive tweeting. People tweet crap more often than value. And the same people do a lot of the tweeting. If I could figure out how to create a pareto chart of tweets per user, there would be 2 or 3 that grossly out-tweeted the rest. And frankly, I don't need someone to constantly tweet quotes (although I did that a bit, I give myself a pass because I'm still a newbie). I haven't decided what constitutes gauche behavior on Twitter yet.

I learned something from Chris Dancy (@chrisdancy, if you're Twitter-savy like me) of Pink... and I've heard it before too: Post valuable content if you want to be taken seriously.

I certainly hope this entry is considered valuable - it's a subjective thing. But it's a risk...