Friday, May 21, 2010

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.


Paul Culmsee said...

The key phrase here is "interacts with other related capabilities in the system".

The issue here is not the role but the manner of thinking, because I have seen this reversed.

Your developer is taking a systems view and thinking in an expansionist manner, while your stakeholder is taking a linear view and thinking in a reductionist manner, by taking the meaning of a label and using that as the absolute truth.

Many times I have seen developers do the same thing as the business guy, when they have not considered vital system interactions when crafting a solution.

Most organisational pain comes from the extremes of these styles of thinking.

The BA isn't necessarily the answer here either - especially when it is based on the paradigm of a "translator" role between these thinking styles. Often the translation itself can be a problem too and make matters worse.

Crude but effective example via google

From English:
“can you build me a collaboration system?”

To Icelandish:
hægt að byggja mér samvinnu kerfi

To English:
“can I build cooperation system”

To Icelandish:
ég byggja samstarf kerfi

To English:
“I build cooperation system”

Here are some more musings on this...


Nicholas Bisciotti said...


You bring up very good points and I love the translation example...thanks for your response!

I just read your post on BA's. I think we are hitting on different, but related points.

Many large organizations have fixed BA roles (one person or group of people's full time job). However, I believe this role is frequently misunderstood. I also believe smaller organizations fail to absorb the necessary functions of the BA role into their project resources responsibilities (assuming in smaller orgs, fewer people have to wear more hats).

On information management, IT projects, I believe the functions of the BA (a person or set of absorbed functions) is critical to project success.

I believe these functions include understanding, in depth, detailed business processes as well as the overall big picture. It also requires understanding technology, solutions, and development processes.

I believe the BA role IS the bridge between the problem and the solution, and I do consider that to be a form of translation.


Paul Culmsee said...

If you wish to get an understanding of why I don't buy into the translator role so much anymore, read the "one best practice to rule them all" series.

Sensemaking is now 90% of what I do - and for IT and non IT projects too. It certainly has had a big influence on why I came to this view...



Blog Archive