We use the automated teller machine (ATM) a number of times, especially now since the banks are reducing teller – customer interactions! Here’s what happens at the ATM:

1.   So you insert the card
2.   Key in your personal identification number
3.   Select withdraw cash
4.   Confirm the amount
5.   Get your card back
6.   Receive the money
7.   Receive the withdrawal slip

Now this is mundane!

When the ATMs were a new technology, the sequence was: insert the card > key in your personal identification number > select withdraw cash > confirm the amount > receive the money > get your card back > receive the withdrawal slip.

Let’s read these two sequences again. More specifically focus on “get your card back”.

Did you notice the difference? In the first scenario, the card comes back before you received the money; whereas in the later, the card came back after you received the money. Almost about 47 out of a 100 users would forget their card in the machine as soon as they got the cash in their hands. Later the banks would receive calls and complaints of lost cards, fraudulent usage, so on and so forth.

A simple change in the sequence of one task, made life so much easier for both the bank and the customer. It was quite a while before the change could come into action. While drafting and designing procedures and systems, a mere inclusion of checkpoints or verification stops are not sufficient.

Verification Stops

It is only system engineers and quality professionals who understand the importance of including a decision box in a flow chart so to say (verification stops). If you were to ask the implementer of that system or the user, to chalk down his procedures, it is most likely there would be no verification stops. The concept of stopping mid-way to verify past events or actions &/or forecasting future pathways, is unknown or conveniently overlooked.

Stop Location

Identifying the check points or verification queries and their appropriate placement in the procedure, is equally critical. Do we need a verification stop after this action / event? Does the outcome of this action or event lead to more than two outcomes? What question would check the previous action / event? What question would validate the next action / event?

Looping

The importance of looping back if event or action is not verified or the outcome of the decision is negative, should be made crystal clear. It is a chance to avoid non conformity, a chance to catch it before it rolls out of the organization to the customer or user, a chance to review areas for further improvement or rework, a chance for internal feedback.

Plug Back Location

Answer yet another set of critical questions – which activity / event does it go back to? and, is it going back to one or multiple activity(s) / event(s)?; or do we have more than one pathways after this action / event?

Bigger Picture

Look at the bigger picture as well. Your department is only one of the many parts of the entire organization. Once you are done with a detailed step by step listing of your activities / events including the verification stops, assess which other departments need to commence an activity / event simultaneously or provide you inputs or get affected by the quality of your output. When do you have to notify them? What is your deliverable to them? What information or action you need from them to complete your job? How does the whole flow fit into an interactive coordinated organizational system?

These five guidelines would assist you travel from start to stop in a flowchart. The task of drafting a good procedure or designing a system is not yet over. The recipe is still missing a few ingredients.

Missing Ingredients

Critical Success Factors or Key Performance Indicators. Identify what will make or break the process. These should also include resources required; assigning responsibilities; measurement criteria; interval of measurement; among other descriptions.

Risk and Crisis Management. No matter how well drafted your process is, it is still not complete until a discourse for the unlikely is included as well. Why do the flight attendants always announce “in the unlikely event of an emergency landing…”? Define the actions required and their sequence if the unlikely is to occur.
While I am only touching upon the topics of Critical Success Factors, Key Performance Indicators, & Risk and Crisis Management, these, however, are separate fields of study in themselves and are not being detailed here.

We can also say it’s an alternate version of the PDCA: the Plan-Do-Check-Act cycle. You start with the end in mind and work backwards.

  • Planning the pathway, actions and resources required, responsibilities, inter dependencies, enablers and target dates. Essentially, yet again, detours are rarely planned. Right at this stage, plan the plan B for the time when there could be a bottleneck or the ideal situation would completely fall off the tracks.
  • This would be followed by the Do part or the actual action, in simpler words, performing as per the plan. This is the least important phase. Suppose you have to bake a cake. You have gathered the ingredients, baking gear and the recipe. Now you just have to mix everything up as it states in the recipe.
  • Subsequently, checking (during the plan roll out or after) whether things are going as per plan, assessing areas of variance or potential areas where variances or non-conformities could arise. For example you have to insert a needle or a knife to assess whether the cake as baked till its core. You realize that the cake has overcooked!
  • Your immediate action is to switch off the oven and pull out the cake to avoid further burn out. You scrap off the burnt layer and serve. This is nothing but a correction. What is required next on your part is to understand the reason why this happened in spite of you following the recipe work by word. The root cause analysis, followed by the actions required to prevent a re occurrence of the same variances or non-conformities.

    • Now, ponder over what if the cake came out perfectly fine!?