I was making coffee the other day with a colleague, and before I added the milk, I gave the carton a vigorous shake. He looked at me quizzically. “Why do you shake the milk?”
“I don’t know,” I said. “I guess I just like it when it’s a little foamy.”
“Ok.” He said. (Hopefully, I didn’t ruin his coffee experience by shaking the milk.)
I thought about it. I like the milk to be foamy, because then I know it has been shaken, and that is the proper way to drink milk, according to my father. So why does my father always shake the milk? It’s pretty simple. He is 80 years old, and he grew up in an era when milk was not homogenized. Meaning, when the milk was delivered in glass bottles, the cream rose to the top (hence the expression) and below it was essentially skim milk.
My grandmother would pour a little cream off of the top of the bottle, and then give it to my father. As the youngest, he took very seriously the important responsibility of blending the low-fat milk with the cream without dropping the glass bottle.
Ok, so that is why my father shakes the milk, but why do I do it? I do it because my predecessor did, and continuing to do so provides a level of comfort to me that things look the way they should.
Sound familiar? When a process has been around for a long time, its familiarity makes it comfortable. Even if it is cumbersome, it is often tough to change, because the old process just feels and looks right. That presents a challenge, since nearly all of our projects have a stated goal of improving the business processes.
The ultimate desired outcome of a project may be cost savings, risk reduction, better time to market, etc., but it generally starts with some kind of examination of the current state workflows and an effort to improve them by changing things. If the project is a system conversion or an implementation, the change to an end-user’s process can be significant. Although everyone may agree that the current process needs improvement, a process that works (even poorly) is often perceived as easier, because it is so familiar. If we want to bring about change, we need to understand each step, in terms of its importance in the flow as well as its significance to the end user. Some steps are critical and cannot be eliminated without introducing risk. Other steps may add little or no value, but they instill a feeling of comfort because that is how a predecessor did it.
As a Business Analyst, your job is to distinguish between the critical steps and those that do not add value. Using our coffee analogy, those steps would include turning on the power, adding water to the coffee dispenser, selecting the right coffee, etc., versus shaking the milk. For any step or process you propose to eliminate, be prepared to address why it is not needed, and be open to feedback from your target audience. Make sure the case for moving to the new, streamlined process is compelling, not just for the organization as a whole, but for your target audience as well. Put the benefits in context for them, e.g. “this will save each of you x minutes every time you do a trade,” or “we’ll show you how this approach gets your orders to market x minutes faster.”
If the new process is very unfamiliar, plan to provide a means for your end-users to engage in some kind of parallel process until they feel comfortable with the new workflows. Otherwise, as soon as you are out of sight, your coffee makers will go back to shaking the milk.