Why Some Things Slip Through The Cracks. To go unnoticed or undealt with; to be unintentionally neglected or ignored, especially in a corporate, political, or social system. With other issues like drug addiction and unemployment taking priority for the government, the welfare of children in the foster system very often slips through the cracks.
Have you ever wondered even with months of detailed analysis supported by multiple rounds of business requirement gathering sessions, solution design workshops, business scenario planning etc, why a few issues and gaps slip through the net? Often the argument, for this is along the lines of that the analysis was narrow, not all SMEs (Subject Matter Experts) were involved, the product wasn’t mature enough, the system integrator didn’t have the right resources, the solution was designed in silos and so on. Certainly, these are all valid points, but I have to disagree with them.
What if you managed to get most of them right and but something still slips through? It’s something I’ve thought about a lot and always look for common patterns, and here are some of my observations:
Curse of knowledge: Believe it or not, the curse of knowledge is one of the main culprits and to be clear the problem is not the knowledge, but it is to do with the bias that is introduced unknowingly. There is a nice article which covers this topic briefly but what interested me is the point that knowing something results in bias. This bias makes it difficult for most individuals to predict other peoples’ behaviour. So true! We assume that everyone will be aware of the information and will also interpret the information in the same way
Same recipe different results: I am 100% sure this is not something new to most people. I can’t recollect when was the last time we were able to reproduce a recipe that tasted the same in our home or at our friends. There is a difference in how people perceive the information (or instructions) and how they execute it. The subtle difference in execution introduces variations in the process and thus results in different outcomes. This is comparable to the user interactions with the system and functions. Whilst we develop numerous processes, scenarios and standard operating procedures (SOP), over time users tend to adopt different variations. It is almost impossible to cover every single permutation and combination of how a user will execute a set of steps.
Heavy focus on the big tickets: Inevitably the focus is always towards the complex and critical functions or requirements. These are the ones that offer the most value, drive operational efficiencies and often give the crucial competitive advantage. On the downside, simpler tasks and requirements when ignored in multiple instances sum up to a significant issue that can disrupt the well-defined process flow built and tested over many months.
And the list goes on, and on.
Let me give a real-life instance to provide a bit more context. I’m opting to an example from procurement systems, one of my favourite and tricky area to work with. Once you get so used to a platform (e.g. SAP), you inherently assume some basic checks (I mean quite basic) are all standard and all platforms have it built-in, but when was the last time you tried to void a receipt after posting an invoice in SAP? Consultants and business SMEs will know it is not allowed but may assume that all platforms work the same way, a bias. The process flow (recipe) is the same in most procurement platforms and yet we didn’t anticipate that a user will void all receipts after invoicing as a different platform, one you are not used to, allows it. In other words, the expectation of users following the training guides/SOPs went out of the window. Although hundreds of scenarios defined and tested both positive and negative, a lesser focus on one low priority check were more than sufficient to disrupt the entire flow.
Well, how do we deal with this? We turned the attention to the data, with a newer lens. I always had the utmost respect for data and these instances have only renewed it and made me feel how crucial focus on data is. Data doesn’t lie and it slaps the facts in our face.
Listen to the industry experts, solution consultants, SMEs and all the wise heads in the room, but investigate the data in the system to see how they all stack up. Pay more attention to issues reported over the years and developing patterns and trend, and don’t limit yourselves to the past few years instead focus on the immediate period when a new solution/platform is put to use for business. The majority of anomalies can be identified here. Before production deployment of a new platform where you don’t have the data to validate, create the opportunity for the data to be prepared for investigation. Simply let a few novice users break the system however they can and see how the basic assumptions stack up. This data will provide invaluable information and hot spots that need to be addressed immediately. Finally, we need to accept the fact that one cannot get everything right, there will be gaps but it is making sure that they are minimized, pose minimal risk, and don’t disrupt the outcome.
I am eager to see what your thoughts and experience are, so please feel free to comment and add what you have learnt.