Using clarity to build trust as a business analyst

Lately, together with some of my business analyst colleagues, I have developed a strong interest in the disciplines of Business Architecture and Enterprise Analysis. I have seen it as a powerful vehicle for providing context to projects and programs of work, helping management make investment decisions and mapping change onto their various organisational units.

I noticed that thinking is developing rather rapidly in this field, but as with many of these things everyone has a view and to some extent jargon is starting to exert its dominion. It is easy to clutter a discipline with words that mean nothing to anyone other than to those that play in that playground. However, if we do this with business architecture, we ignore at our own peril the very customers that we serve, the business stakeholders.

Recently I was working with a colleague within an organisation to help them understand the context of a large program of work. We decided to apply some of the Business Architecture concepts we have adopted such as Primary Activities and Business Capabilities. We produced a diagram (which by the way didn’t follow any standards but simply communicated these concepts) and used a spreadsheet to define and map these concepts to requirements. Then we tested it, at a large workshop and guess what: it worked! While there were different views as to what the processes should be they had a reference and a “picture” to discuss.

Not long after the workshop one of the business people was asking a business analyst to explain the concepts in the diagram. He referred them to some definitions we had prepared, for example we had defined a Primary Activity as “something the business does”. Straight away the person said “I can understand that!”

So what do you reckon? Is it time we as business analysts speak plainly even though we may risk some vagueness or would you rather be 100% precise and risk losing the customer? Don’t get me wrong requirement specifications need to be specific, testable and yes unambiguous but communication above all things needs to be understandable.

I believe one of the reasons the business do not trust IT is because they don’t understand it. Some folk may relish the need to be needed even if it is to explain something that they obscured in the first place. I’d rather be trusted because I make myself clear.