I often hear that we need a business analyst to translate what the business people say, so that technical people understand them. Then, I am told we need the BA to then translate what the technical people say, so that the business people understand them.
I guess it goes something like this:
It sounds good, but actually I don’t think it is true.
In fact if this is all the BA does then he or she is really an “order taker” or maybe a “Business Messenger” or a “Business System Messenger” or something, rather than an “analyst”.
To be a business analyst I think we need to analyse what is said and communicate the implications, rather than just communicate the initial request and the technical response.
“Of course we do that,” I hear a BA saying – but do you really? If you do then I think we need another axis on our diagram.
Here is what I think the “translation” is really about:
In other words I think the BA needs to be translating a symptom into a root cause BEFORE helping the business translate their need into a request for a feature.
Or in another project the BA needs to help translate a requirement into the core needs that it is hopefully addressing. Let me show you how this conversation goes.
In the original model the BA translates what the business stakeholder asked for.
The business person tells the BA that they need a new feature. The BA can “translate” this to specifications for a new feature, then the BA can help the technical expert deliver that feature. But then the stakeholder might notice that the new feature did not actually remove the pain at all:
The BA can claim that he or she accurately translated what the business stakeholder asked for (into the right specifications) and that the feature is exactly what the stakeholder asked for.
But the BA cannot really claim that he or she performed good analysis.
Instead the BA could help clarify the stakeholder’s understanding of the symptom (the current pain point they identified).
Then, through a bit of analysis, they can help the stakeholder understand the root cause of the pain and the real impact that it is having. Perhaps the root cause is causing many other pains that could be addressed at the same time … or perhaps it is actually having both a positive and negative impact in different areas.
Now the stakeholder can make a far better decision about what they want. So now the BA and the stakeholder explain what is needed to a technical expert who explains that the best they can do is a tactical solution, unless they can have a substantial budget for investigation and building of warp drives. What the business person hears is that there is a cheap fix or an expensive fix. But this is not what the expert said. In fact what the BA needs to translate is that there is a quick fix that will leave a workaround, which will actually place constraints on the business, which might limit future opportunities.
So there is a cost to implement the solution AND a cost to live with it when it is in place.
That changes things a bit so the stakeholder might now say that he or she wants the job done properly. The technical expert explains that this is possible and proposes a solution.
But the BA reveals that there is actually a cost to create the solution AND a cost to change things in the business to make it possible to use the solution … oh and there is another requirement to transition from the old to the new solution … with some data conversion, some parallel reporting and other things.
So the feature that the business needs to meet their requirement needs some architectural changes, which cost money. But to benefit from the new feature, there also needs to be some change on the business end, which results in more requirements and maybe some more features or help from the expert as a result.
The BA did not know this to start with, nor did the stakeholder and nor did the technical expert. But a series of meaningful conversations led to the shared understanding of what is needed
That takes a bit more doing – but it saves the technical expert being blamed for delivering a solution that “did not actually take the pain away” when in fact the solution would have worked well … IF the business had made some changes at their end.
But then we discover that there is another discussion that may benefit from some “translation” or facilitation support. The technical expert explains that they can implement a fundamentally good solution, and that it will have a number of cool features, but that these features can be implemented in any number of ways. So the BA helps both the expert and the stakeholder understand the options and priorities for the different features.
Otherwise the technical expert may deliver something that is good and that should address the root cause, but that is implemented in a cumbersome and not very useful way, when with a little more effort it could have been an amazing solution.
That looks much better. Unfortunately it will take a while to implement and the business is in pain right now. Maybe that tactical solution with the workarounds is not so bad after all.
But there are ways we can provide a short term fix that limit opportunities and there are ways that allow us to still build a long term solution. There are also expensive long term solutions and cheap short term solutions that get the business out of trouble quickly and let them worry about other things. Which is better?
Again nobody knows. The business do not know what is possible and the expert does not really know what matters the most to the business stakeholder.
So now we need another conversation about which options make sense (either on their own or combined together). Sometimes the stakeholder and the expert can do this on their own, and sometimes it helps to have a facilitator.
This is the difference between an order taker and a good business analyst. An order taker will take your order, translate it for the cook (or vendor or developer) and then let you have what was delivered. A good business analyst translates an initial understanding of a symptom (or idea) into a shared understanding of the real needs and opportunities and the real solution options and implications.
So I guess that leads to the final question that I will leave you to answer. What value do business analysts add in your organization … and what value could they be adding if they really get going?