Layers of Preferences Disguised as Requirements

Think about the old game of "telephone" where a message starts at one end of a group and the message is whispered from person to person down the line. This is often how process instructions and requirements are shared. Someone performs the job when the process is first created and as the process is passed from person to person due to turnover, expansion, etc. the message slowly changes.

It has been my experience that often over time, the personal preferences of individuals are included in the job requirements as the job information is passed on. When Mary shows Michael how to file a request, she includes that he should use a red dot for government and blue dot for commercial requests. This was not an original requirement, but a visual cue Mary used to speed up her filing. As Michael continues his work, he always remembers to add the appropriately colored dot, but doesn't really know why it is needed. When he trains his replacement Sam, he passes on the instruction to color code the files. For years and over many staffing turnovers, the color coding gradually evolves and possibly expands.

The team finally moves from paper files to a new electronic record system and it is time to gather requirements for the new system. Charles, the current request filer states that a "must-have" requirement for the new system is the ability to enter in the "color" of the request. In reality, this is not a true request, but a personal preference of someone years prior that has slowly made its way all the way to a requirement.

Don't get me wrong, the initial functionality of the colored dot was sound. There probably still remains a need to be able to quickly sort between types of requests. There are now much more efficient methods to reach that goal. One can achieve the same effect using filters and data visualization rules without adding the additional administrative work for employees of adding the request "color" to each record.

Sometimes it takes someone from outside of the process to ask the question "why?" over and over to understand the true requirements. Sometimes it is easier when the person asking the obnoxious questions with obvious answers is not part of the organization. That is be benefit of hiring an effective business consultant. We can ask the questions that everyone assumes have obvious answers and dig down to the core requirements.