Tag Archives: business analysis

Uncategorized

Dealing with Resistance to Sharing Information

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: 
  • Maintaining Value 
  • The Oral History 
  • Revisionist History 
  • The Outsider
  • Mysteries of the Universe 


Maintaining Value 
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. 
Revisionist History 
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. 
The Outsider 
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. 
—– 
Sway presentation – https://sway.com/EaaqnI4TND9A43Kp 
Uncategorized

Keeping emotions out of requirements gathering

When was the last time you went to an amusement park with a group of kids?  Remember the car ride there, the excitement, the buzz going on in the back as each kid talked about their favorite parts of the park and what they were going to do that day?  “I want to ride Hydra!” “I’m going to the water park!” “I want to ride Steel Force!” So much energy, so much emotion, so…how are you planning to fit it all in one day?  You know you have to because if you don’t you’ll be headed home with some very disappointed kids in the back of the car.
Gathering requirements often has a bit of this involved as well, but with less funnel cake.  Stakeholders commonly have pet parts of a project that their primary focus and energy is repeatedly drawn to.  It can be user experience, graphic design, dashboards, data integration, etc. but it’s something that at some point became a hot button for that person. In the process of gathering business and functional requirements these emotionally enhanced requirements will rear their heads again and again, circling unrelated conversations back to these topics with the threat of derailing the conversation once more.  How do you make sure you address all the needs while still keeping peace in the backseat?
All requirements are not created equal…but should look that way
As requirements are gathered, one of the biggest challenges is to avoid the appearance of weighting one set more strongly than others due to the stakeholder providing them.  Strong emotional arguments, passive aggressive tendencies, and unwillingness to compromise can lend a gravitas unwarranted to certain requirements.  Capture all the requirements as a scientist would take laboratory measurements: noting the source, details, and other observations but not passing judgment on the value and impact in the initial steps.
If a topic demands an audience, give it a private showing
If you have a topic such as design or user experience repeatedly derailing your main requirements gathering efforts, schedule a session focused just on that topic.  This provides you the opportunity to parking lot this topic away from the other discussions.  Additionally the stakeholders benefit from the sense their hot button topic is receiving the important exposure it deserves.  Think of it as having the kids who aren’t riding the rollercoaster waiting at the bottom until the ones who are finish.  It doesn’t take long but in the end you’ve defused a potentially difficult situation.  Just make sure if you do these special sessions you maintain a balance with the other topic areas as well.
Measure based on measureable things not based on opinions
When you near the end of gathering your business and functional requirements and are ready to start setting priorities, you could be walking into a minefield if you don’t plan ahead.  Set your measures for prioritization around factors such as cost, time, difficulty, scope impact, etc.  Do not score requirements based on intangibles such as impact, value, customer satisfaction, etc.  Basing your measures on those types of intangible measures is just setting yourself up for derailment with one or more requirements being pushed due to a perceived but unproven value touted by the emotional champion of the topic.  In other words, a 50-yard touchdown is a 50-yard touchdown, no matter how much cheering the fans do.
To paraphrase a classic 80’s song, “people are people so…”
It will be a rare instance indeed when you do not encounter some emotionally driven requirements on a project.  People formulate their own measures based on experience and motivating factors.  While you have to take these into account, you don’t have to let them set the tone for your entire project.