Where should Business Analysis reside within the organisational structure?

Recently I was invited to a meeting of the Austrian IIBA Chapter by one of the board members who happens to work for the same client as I do. The topic for the evenings discussion was “Where should Business Analysis reside within the organisational structure?”.

The prelude

To be honest I hadn’t given this topic too many thoughts before and therefore I had no fixed opinion on it. A quick check of the BABOK also doesn’t reveal any guideline on the issue, since it only states “Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.” Well, actually, I never expected to find the answer there. How could they even give the one and only answer!?

The discussion

The evening started with three short key-note speeches and continued with an open discussion. All three speakers and all participants in the following discussion described drastically different organisations and set-ups that they were working in. There was a good mix between internal employees, some were external employees working for consultanting companies, some freelancers like me or running their own business. In most organisations Business Analysis was a part within the IT-organisation, some were considered to be part of Demand Management, some as an executive department.

Of course, everyone agreed on the common places “business analysis is a bridge between business and IT” or “business analysis has to consider all sides”, so therefore “they should be part of IT and business at the same time”. Don’t get me wrong, I also fully agree with these statements, but they are so general that they don’t deliver a lot of value when it comes to the questions of how to set-up Business Analysis in a real-world organisation.

Benefits of different alignments

After the discussion I was hooked and started searching for more information. One of the first things I found was a comprehensive article by Lora McCoy “Where Should the Business Analyst Reside?”

Lora McCoy mentions advantages and disadvantages of different alignments of Business Analysis. The main advantages of an alignment with IT — as it was most commonly stated during the discussion evening — is “that Business Analysts understand the technical capabilities and feasibility of solutions. They can offer technical solution options and easily relay information to software engineers about the solution requirements.”

As you’d imagine, there is also a disadvantage: “When you’re aligned with IT, every problem gets solved through technology. This is the case even when the best solution isn’t technology based. Perhaps the real problem can be solved by a simple process change or better communication. This type of bias leads to sub-optimal solutions.”

This relates well to what I frequently experience on projects. If you are already set up on an IT solution, you lack the oversight to reject or propose a drastically different that requires some painful organisational change.

A Business Analyst that is part of a business department will always have the better leverage when it comes to understanding the business and people in it, however, “because you’re so imbedded with the business functions on a daily basis, it’s difficult to think holistically.As a result, upstream and downstream impacts of changes may be missed. Additionally, you may be unable to see innovative or disruptive solutions because you’re too close to the problem.”

This relates well to a side-note one of the participants made about rejecting a business department’s demand for a new CRM, because there was work on a corporate wide solution which, in turn, lead the business department to pursue their own shadow solution. Sunk costs. Had the business better understood the how corporate IT works, that could have been avoided.

The downsides of any alignment leads McCoy to conclude that “Instead of alignment with IT or the Business, being part an objective, strategic group outside of both of those areas brings together the best of both worlds.”

She admits that there it needs “a certain level of maturity and openness to learning”, but fails to see the outsider dilemma. She acknowledge that IT will see you as an outsider when you are aligned with business, and business will see you as an outsider when you are aligned with IT. Maybe it’s only my lack of imagination, but why wouldn’t there be a risk that both see you as an outsider instead of a valuable and unbiased consultant?

My “responsible for the money” hypothesis

Now maybe it has to do with my personal understanding of what I do day in day out and not so much with the definition of the BABOK, but I want to deliver value. As an external employee you should always strife to deliver the most value possible to your client. As an internal employee maybe that’s not always of the same importance, but it should be!

The issue with delivering value is that value is perceived in very different ways. Value to the IT deparment could mean a simple solution with low maintenance costs or high flexibility for furtehr developments. If that leads to a solution that oversimplification the business problem, value will be perceived quite different by the business deparment.

So whose value is it that should be important to you? You could answer the “company as a whole” and that’s true in general terms, but just like above, a definition that is too broad and general doesn’t help you much in the real world. So my more practical hypothesis is: You are responsible for the value of the one whose got the money. Don’t get me wrong here! I am not talking about being a puppet of your master to cash in the next pay check! I suggest you to ask yourself:

• Who is paying for all of this (project / program / development / demand)?
• How can they get the most value for the money they provides?
• Is it possible to achieve the same result for less?

If business side pledges the budget, their money has to be used in the outmost economical way. At the same time they need you to help them understand the real limits of IT. If seen both, IT keeping quite about the impact and the long term costs, but I’ve as often seen IT overstating the complexity of a solution just not to adapt to change themselves.

If IT owns the budget for changes and has to prioritize the wave of demands, you need to help them to understand the given business problems, so they won’t just listen to the one who shouts loudest. Business will overstate problems and priorities given they don’t have to pay for the remedy.

The payer needs you! As a consultant and as an advocate.

Me and Lean Coders

My name is Patrick Schmöllerl. I work as a self-employed Business Analyst, currently with a focus on Requirements Engineering. I met Christoph on a project where we were working together on an e-Commerce solution for our client. I hold him in great esteem and therefore, when he asked me about writing a guest post for his blog I was more than willing to do exactly that. If you want to find out more, check me out at patrickschmoellerl.com