Lather, rinse and repeat your process

shampooLather, Rinse and Repeat (LRR). Straightforward 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 is the problem?

On the positive side, the process is simple and easy to understand. However, the biggest issue with it is “Do I really need to repeat”? “What happens if I don’t”?

So what’s the point with regards to ITSM?

  1. Let’s first look at the positive to LRR, it’s a simple process to follow, it isn’t 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 cool systems that do cool things? Or can we learn from the simplicity of LRR?
  2. Another plus point to LRR, the process is universal and aimed at the end-user. Regardless of why or where you have bought your shampoo, you know what to do with it when you are ready to use it. You can execute the LRR process with little training and/or thought. With regards to ITSM do we design processes to help our customers or to help IT? Can customers execute IT processes with little training and/or thought? It is always interesting to ask why we (IT) do something. It is shocking to see how many times the reason focuses on making things better for IT and not for customers.
  3. Then there is the negative, is the process a) even necessary, b) actually adhered to (I can’t say that I lather my hair twice, do you?). 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. In ITSM do we spend time looking at how to make a process better?

Ok but seriously, what can ITSM learn from a shampoo process?

As ITSM practitioners, do we take the time to think about the processes we ask others to adopt? Do we work to remove obfuscation? Or do we trot out big ideas/opinions regarding how IT should work? To me, LRR is a reminder to design processes that can be easily executed and deliver desired results. With that in mind, here are my tips for process design.

Tips for process design

  1. Keep it simple – look for redundant steps. Remove points of “distraction” from the process flow. Ask frequently, “do we really need this step?” AND “what value does the customer get from it?”. If you cannot answer the value question, most likely, you do not need this step of the process. Other tests to verify your process is simple – can people easily explain and discuss the process? The more complex the process is the greater the chance that people will not internalize it and probably will not discuss it with colleagues and customers. If the team is not willing and/or capable of talking about the process, how will you get continual improvement to happen?
  2. Make it elegant – keeping it simple should not translate into “skimp on feature”. You should design processes to meet the needs of the business and to be easy enough to execute. The context of your situation should drive how elegant your process needs to be.
  3. Customer first – design every process with the mantra of “Customer First”. Take the time to learn who the customer is, why they need the process, and what they expect from the process. If you determine that there is a gap between expectation and delivered value, determine how to close the gap.
  4. Borrow liberally – don’t keep “reinventing the wheel”. Look at other processes (both inside and outside of your organization) and determine if the process/steps fit the context. If so, use them! The benefit is that IT teams should not need to undergo additional training since they already know how to execute specific steps. In fact, if I am in a service owner role, I would ensure that I look at the processes of my fellow service/process owners, and when I find a process that will work for my situation, I would simply declare “I follow team x process”. Doing this would alleviate me from the ownership and management of the process and documentation, but would also mean that I must work to build/maintain a partnership with the other service/process owners.
  5. Test – verify what you think will actually work. Get feedback from the folks who will execute the process (in fact, do this all the way through your design). Ensure the process will meet the expected business outcomes. Do not launch a process that will not meet needs or is not ready. At the same time, do not try to make the process perfect. Doing so means you will never launch simply because “it just needs a little more tweaking.”

Spend time in the design phase determine what constitutes “success” for the process and make sure you measure as you test.

Then, with all of the steps above: Plan, Build, Test. Lather, Rinse, Repeat.

It really is that simple. And yes, the idea for this article came to me in the shower.

Image Credit