Lather Rinse Repeat

LATHER RINSE AND REPEAT

Lather, Rinse and Repeat(LRR). Pretty straight forward instructions. Hard to mess up. Or is it? If you follow these instructions, when do you stop?

The phrase has come to be indicative of two things; a) a way of pointing out instructions, if taken literally, would never end (or would continue at least until you run out of shampoo), or b) "a sarcastic metaphor for following instructions without critical thought". The author Benjamin Cheever wrote about these words in his book "The Plagiarist" (SPOILER ALERT - in the book, a marketing executive becomes an overnight legend by simply adding the word REPEAT to the instructions. Of course, sales of shampoo skyrocket)

The point is this, this is a process and the process has not changed or been updated in a long while.

Are you sure it's a process?

Yep. Here is how I know.

The base statement of "Wash Hair" does not cover the steps needed to complete the activity. LRR fulfills the steps. LRR is not a procedure as the activities do not provide instruction on how to complete the steps.

So what's the problem?

The biggest issue with the process is "Do I really need to repeat"? What happens if I don't? Maybe my hair doesn't have the body promised? Maybe my hair is not sleek and shinny? Oh, perish the thought! My reality is I lather and rinse once. The only time that changes is if I have been doing an activities (painting, exercise) that cause me to feel my hair to need another cycle.

So the point is?

a) It's a simple process. Not complicated. Do we work to make ITSM process as simple as possible? My experience shows that we, as IT people, tend to grab Visio, graph every possibility without question, and produce a monster swim lane diagram. Do we add complexity because the customer requires it or because we have these cools systems which do cool things?

b) Do we spend time looking at how to make a process better? Lauren Goldstine takes on the need for LRR in a 1999 article entitled "Lather, Rinse, Repeat: Hygiene Tip or Marketing Ploy" In her article, Ms. Goldstine indicates that Repeat is probably no longer necessary due to the advances in shampoo tech, yet most shampoo bottles you look at will have the process. 

Now to be fair to the shampoo companies, having Repeat on the bottle may help drive sales, thus the reason for no change. I am highly suspect of this reason simply because I don't buy shampoo based on the process. I buy shampoo based on a) does it help make my hair look good? b) can I afford it? and c) do I have a coupon?

 I'm also willing to bet the shampoo companies have done research to know what the preference of the consumer is. There is also the possibility the companies have looked into the change and decided it is cost prohibitive. I don't know how much it cost to print Repeat on a bottle or how much it costs to stop printing Repeat. Regardless, do we have plans to review our ITSM processes and to adjust based on our customers' needs?

c) Are our processes designed to help our customers or help IT? LRR is clearly aimed at the end user. One buys shampoo for many reasons, but the process is almost universal. You know what to do when you are ready to use shampoo. You can execute the process with little training and/or thought. Can customers say the same about IT processes? It is always interesting to ask  why we (IT) do something. It's shocking how many times the reason focuses on making things better for IT not for customers.

At the end of the day, does this really matter?

You bet it does. The tide is turning quickly for IT. The business wants to know why IT has spent all that money and what value did the business get. What better way to show the value than to show how IT improved business outcomes. The business is treating IT line a partner and IT needs to reciprocate.

They call me the fireman...

My apologies to George Strait, but the call me the fireman. Why? I and my team spend the days of our lives fixing crisis. We're good at it...too good. People have come to expect that we will respond to any crisis with passion, commitment, speed, and caring. While its great we can do this, it is truly a bad thing.

We had one of the worst events that you can have in a hospital last week, a small 2 second blip in power. Short enough to just be noticed, not long enough for generators to kick in. Because we have an aging facility and lots of construction going on, we have become somewhat accustom to power issues, not to mention the squirrels that have sacrificed themselves on a transformer. We have developed a rapid response plan to deal with theses blips.

Last week, the team executed the plan almost flawlessly. The only problem they had was me getting in the way of the process (sorry guys!). The team quickly and efficiently went through the floors, verified operations, and rapidly started repairs/hot swaps on anything that did not recover. We found we had some training opportunities and needed to tweak our process just a tad.

What is bad about about this? We do it so well that staff want it to be the "standard". The problem: We can do that, but what/how does it help the IT team be more productive in the future? How much do we increase cost with this model? How can we provide the same perception of service in our "normal" operations?

Not always easy questions to answer, and in some cases, not easy changes to make. But when is change ever easy?

I don't like being known as the fireman. You only call a fireman when you think something is terribly wrong. I would rather be know as Smokey the Bear (...only you can prevent...). We need to fix our processes so that we watchfully tend our fires or, better yet, we don't have them at all. Sure, fixing our processes to prevent fires will be just as tough, but isn't that better than (my apologies to the Talking Heads) burnin' down the house?