Building Trust Through Business Analysis
Trust is the most important aspect of any relationship and a business-to-business relationship isn’t any different. But how do you build trust? I use the verb “build” because if you have the materials, you can create something that starts out small and continues to grow as you add more materials and perform the labor.
While there are many ways to build trust, I'll focus on four key ways to grow trust on a project: listening, vulnerability, simplicity and follow-through. These are the keys to building the level of trust necessary for a successful software project.
Listening is one of the most valuable skills for building trusting relationships. Jim Rohn, author and motivational speaker, once said, “One of the greatest gifts you can give to anyone is the gift of attention.” Listening is hard to do because you must cede something (giving a gift) and listening to someone makes them feel important and appreciated (receiving a gift).
I’ve often noticed that the people I admire most and that I enjoy spending time with in my life are those that willingly give me the gift of their attention. I walk away from the conversation with them and I feel energized and important – only to realize that they didn’t really say anything at all. It was a one-sided conversation where they were giving me the gift of their attention.
Elicitation sessions, client calls and other communications with stakeholders are the business analyst’s opportunity to give the gift of attention. Your stakeholders are dying to tell you about their business needs. However, they don’t always know how to articulate those needs. You must pose questions and create an environment in which you can extract the information.
The more you listen, the more the stakeholders will say. And when you can take that information and repeat it back to them concisely, you know you are on the right path to satisfying the business’ needs.
Vulnerability is the ability to let others win. Believe it or not, being right is not the way to be successful. Instead, it’s more important to have self-awareness to see your own mistakes and allow others to see them in you as well. This builds trust.
Each of us has within us the desire to be right; this is part of our competitive nature.
Think back to your time in kindergarden when your teacher asked the class a question. You know the answer and so does the rest of the class, so you all raise your hands and furiously shake them in the air hoping that the teacher will call on you. Luckily she calls on you and you get to answer the question. This feels good, doesn’t it? You got to answer the question first and you got that emotional rush from being right.
Now suppose in that same situation the teacher calls on someone else. Another student gets to answer the question and you lower your hand in disappointment. You didn’t get to answer the question; even though you knew the answer, you didn’t get to prove it.
Being right causes a flood of positive emotions in us but at the same time it can cause negative emotions, like disappointment or embarrassment, in others. If you can recognize that letting others win makes them feel good, you can build trust. In order to do this, you must be comfortable with the uncertain feeling that comes with vulnerability. According to Dr. Brené Brown, a research professor at the University of Houston Graduate College of Social Work, vulnerability is something that we admire in others but rarely have the courage to show in ourselves.
When working with stakeholders, it is okay if you don’t understand or have the answers. In fact, the best business analyst is the curious business analyst that isn’t afraid to ask for clarification — or simply say “I don’t understand.”
In order to be curious you must deflate your ego and allow others to teach you. Become a student of your stakeholders' business and their needs. This is the only way to get past what you think you know about your client and dig down to the requirements that will support their success. They may speak a technical language or marketing language; whatever it is, you need to learn to speak their language.
Simple, concise and straightforward are all words that I use to describe great project requirements. If you can’t explain an idea simply then you don’t understand it well enough. That means that if I don’t understand your business need then I can’t meet that need with an appropriate solution.
Unfortunately our brains can be lazy and – just like electricity – take the path of least resistance when faced with a vast amount of disparate information. The first thing we try to do is place that information into categories and simplify it so that we can understand it.
Imagine you are at a restaurant and instead of seeing the appetizers in one group, the drinks in another group, the entrees in another group and so on — the restaurant has made the decision to mix the appetizers, drinks and entrees all together on the menu. The first thing you do is look for all the drinks among the other items on the menu in order to group them together and make your choice. Then you do the same with the appetizers and entrees.
Sounds like a lot of work, doesn’t it? Our brains like to consume information as simply as possible because our brains are lazy. Fortunately for us, restaurants have recognized this shortcoming of our brains and they have categorized their menus in order to make our dining experience as effortless as possible.
Just like restaurant menus, you must present the requirements that you’ve defined as simply as possible. The business analyst is the funnel that has the ability not only to capture all the information at its widest point but also to transform that information into concise requirements.
The goal of sending the information through the funnel is to show that, “Yes, I’ve listened to what you’ve said and this is what I understood.” There’s an incredible amount of trust that is built when someone knows that you are not only listening to them but that you understand what they are saying and you can articulate it back to them.
Creating requirements that are simple, concise and straightforward isn’t as easy as it sounds, though. Business analysts look for themes in the information and tease out those themes to repeat them back in a variety of forms as concise requirements.
There are many techniques for eliciting the needed information from stakeholders, including workshops, prototyping, brainstorming, interviews and research. However, sifting through the information to pull out the core of the need is where the business analyst shows their value.
Just like organizing a menu, it is the business analyst’s job to identify these ways of categorizing information — even if the client doesn't present them in a categorized way.
Follow-through consists of two parts: what I say and what I do. When there is consistency between what I say and what I do, I know that I am following through.
Before trust is built within a team, people tend to look for gaps between what you say and what you do. For example, I say I’m going to deliver a blog post of 1,500 words by the end of the week but I deliver the blog post late and it only contains 1,000 words. You probably won’t trust me when I say I can deliver the next blog post on time and with the appropriate amount of content.
Follow-through with respect to project requirements is the traceability of requirements from the beginning of the project to the end. The job of the business analyst is to ensure that what gets defined as a requirement is what gets built, tested and delivered.
You don’t want to have any surprises when the solution is delivered. No surprises! In a software project, surprises are viewed as a negative outcome; set expectations as soon as possible (what I say), and deliver a solution that meets those expectations (what I do). Connecting what you say and what you do equates to follow-through.
Listening, vulnerability, simplicity and follow-through are the keys to building trust, which forms the core of the most successful software projects. The great part about trust is that the more of it you have, the less you need to have to mitigate risk because the risk mitigates itself.