Whether you are a consultant, business analyst, project manager, or just a professional tasked with gathering information from other people, you will at some point run into people who are resistant to sharing what they know. In this article we will take a closer look at some of the causes of this behavior and ways you can get around the roadblocks to the information you need.
The business analyst often runs into a difficult situation caused by the unwillingness or inability of the stakeholders to share information about their requirements in the process of capturing business requirements for many projects. This can also be seen in instances when business team members need to share information about how or why business processes function the ways they do. There are a variety of reasons why team members can be resistant to sharing information, especially with an outside consultant, so I'm going to focus on five of the most common areas:
The Oral History
Mysteries of the Universe
Many of us have either experienced this situation directly or have heard the story about the person who wouldn't share. These are often the team member or members who ascribe to the adage that knowledge is power and retention of that knowledge is control. The intensity of this can vary from organization to organization, department to department, even individual to individual. In cases where it is an individual resistant to sharing information to maintain their own value to the organization, you have the option to involve others in the conversations to get the flow of information moving. In situations where the restriction of information is at a departmental level, such as I.T. not sharing information about reason and rationale with business units or vice versa, executive involvement may be necessary to remove roadblocks.
The most important thing to keep in mind and to share with the parties involved is the importance of the information to the overall engagement. If the person feels the information they place such high value on will be trivialized then they will be far more reluctant to put it on the table. Take opportunities to separate hesitant people from the main group and interview / interact with them directly. While this is more labor intensive, it can be reassuring to those who feel their information and role in the engagement are not being given the perceived level of importance.
Juxtaposed to this is the person who feels their control of information gives them power over a situation, often at a station beyond the norm for their role. While less common, this roadblock can be more difficult to overcome because the person withholding the information has determined, wrongfully so in the majority of cases, that hoarding the information is in their best interest. Sometimes this happens infrequently as a form of personal rebellion rather than a conscious effort to maintain informational isolation.
The Oral History
In many organizations, no matter how much stress is placed on documenting functionality and processes, there are a number of things that are kept to those "in the know". This information is shared not through procedures but through informal conversations; you can recognize these often by their preface with "You should remember this..." or "By the way..."
It's this informal oral history that accompanies existing processes, especially long term legacy processes, that can challenge the gathering of details which can have a substantial impact on the success of the engagement as a whole. How do you gather the undocumented steps on a process?
Often we rely on users to supply us with written documentation for review and building business requirements but there is no replacement for the visual demonstration of processes in action. Being able to observe and discuss how a process is executed, identifying edge cases and stray steps not captured in formal documentation, is an excellent tool for a business analyst to use in cases where they sense there may be more to the story than what is being shared.
Just as treacherous as a lack of information for requirements is misinformation. It is unfortunately not uncommon to have business requirements shared that are not an accurate representation of the system as it exists but rather are how the business users think the system should work. For example, when reviewing requirements for a form design the conversation consistently turns to "It would be much better if..." or "It really should do...". If you are in the stage of capturing what is desired this information is valuable, but if you are trying to identify current state, it can be a waste of time.
Watch for key phrases and inconsistencies in how people describe the functioning of system vs how they have been documented. Often those inconsistencies come from the same people over and over again, possibly revealing a personal agenda overshadowing the fact finding you are performing.
Often a consultant runs into a situation where information is not shared due to the very nature of the client / consultant relationship. Clients can be resistant when they feel, unduly, their work and knowledge is going to be usurped by the consultant. This can also happen in environments where the operational stability is in flux for the individual or team.
In these circumstances it is critical to focus on relationship building with members of the team until such time as both sides feel comfortable information can be shared to a mutual benefit. Getting clients to recognize the consultant is more than just a "hired gun" can be the difference between open discourse and a strained situation.
Mysteries of the Universe
There are cases where hindrances to sharing information come from not a willing resistance but from a lack of information itself. It is not uncommon to find business users executing processes as they were trained, doing the job well, but with no real idea as to why the process needs to be done. Pressing a business user on the why can sometimes shut down the communications channel about the how if they become uncomfortable with their awareness of their lack of knowledge around a process or procedure. In these situations, you need to identify if the information is necessary for the effective execution of their role (apparently not) and where else could that information come from without placing undue stress or unwanted attention on the business user. If you are able to locate the "why" from another source, find out if there is any issue with sharing the "why" with the business users who did not know the answers. In many situations, if there are no managerial restrictions, the sharing of information can open doors with business users to either provide additional details or at a minimum build bridges between the users and the consultant.
Keep the Information Flowing
These five areas only scratch the surface of roadblocks you can encounter when gathering information from business users. As you complete each engagement, make part of the post-mortem a review of how the process of information gathering went, what could be improved, and what were the warning signs for future engagements. Business analysis lives and dies based on information and keeping that information flowing is a key to success for many parts of an engagement, not just the requirements stage.