How Communication Gaps Can be Viewed as Opportunity for Business Analyst Function

I find myself analyzing things quite a bit throughout the day. Some people accuse me of thinking too much. I don't know, it is just a natural thing I do, I guess. I ponder a lot.

One thing I ponder about from time to time is the impact that words have on work, people, and communications in general. Words are very significant in my profession. Words appear everywhere. In Web portals, they are used to instruct people how to use the Web site or how to perform a function. In presentations, words are used to concisely deliver a big message, one little message at a time. A funny thing about words is how they conjure up different emotions and different meanings to different people.

So, how does all of this relate back to the theme of this blog? Well, UX topics aside, there are some interesting behavioral patterns that I recently noticed, because I had been fixated on words. Recently, I happened to be observing a debate between colleagues, regarding the best way to configure a feature of a new Learning Management System (LMS). For background, this LMS Web application is intended to deliver courses and track professional development information for employees. It happens to be a third party product.

During the course of debates I realized that there is a distinct difference between the way that the software developer interpreted the name of a software feature versus the way that a business stakeholder interpreted it, in the context of them working together on the system implementation. Both individuals were working together, exploring how the third party application works, and trying to figure out the best way to leverage the product in order to meet the business requirements.

During this adventure, the two individuals came across a product feature called "curriculum." Here is the behavior that I noticed:

The software developer evaluated and experimented with the "curriculum" feature and tried to figure out different ways to use the feature in order to meet the business requirements.

The business stakeholder, performing the same experiment, forcefully attempted to make the software behave as they understand the word "curriculum" to mean in normal business context.

The two individuals then reached a disagreement when the software developer offered various options for how the feature could be used, while the business stakeholder argued that "no, a curriculum means this and so it must only be used like this." Not only did the two disagree on what the word means in general business context, but both also disagreed on the appropriate way to approach the software configuration task.

Do you see the distinction?

The software developer views the "curriculum" not for what the label means, but for what the actual program capability is and how it interacts with other related capabilities in the system. On the other hand, the business stakeholder had a fixed idea because of the label.

What is the point of all of this? Business analysis. A business analyst function is extremely important on a Web application project. Whether this function is performed by a dedicated expert, absorbed and performed by the project manager (or other resource), there needs to be a person who can understand the business requirements while also understanding the developers' way of thinking so that these two perspectives can be united and a common goal can be met.