Does a Business Analyst Need Subject Matter Expertise?
I see a lot of job openings these days where companies are looking for “business analysts” and requiring applicants to be knowledgeable in a specific subject matter. I must admit that I have a beef with that requirement. I would maintain that too much knowledge about a specific domain is detrimental to the duties of a true business analyst. My reasoning has to do with a very basic tenet of how we as human beings learn.
The Learning Process and Requirements Discovery
There are 4 fundamental states that I as an individual must pass through to acquire knowledge in any topic:
- “Unconscious ignorance” is the state in which I have absolutely no idea of all the things I do not know about a specific domain. This is the initial state for everyone upon being introduced to a new domain.
- “Conscious ignorance” is one step up the ladder. I am now aware of some of what I don’t know about the domain. It is during this phase that I am actually able to phrase intelligent questions that someone with more domain knowledge than I (i.e., a “subject matter expert”) can answer.
- “Conscious knowledge” is achieved when I actually know something about the domain. I gain this knowledge in part from the answers I get to my very intelligent questions. I now know something that I can at least repeat and, to some extent, explain to others.
- “Unconscious knowledge” is a state in which I do not have to think about what I know. I have incorporated the new knowledge into my way of thinking. If this knowledge is about how to do something, it is called “Unconscious Competence”. I can do it without thinking about it. I am now the “subject matter expert”.
Interestingly, I only need to concern myself with the first three states because the fourth one is dangerous – for me in my role as a business analyst. I need to achieve the state of “conscious knowledge” to be able to understand what the subject matter experts are saying and to be able to help them define the business and stakeholder requirements for their project. My awareness of these states of the learning process helps me plan and prepare for effective requirements discovery.
The Power of Being Unconsciously Ignorant
At the beginning of any project, I know the least about the domain. During this phase, it is difficult to determine what questions I need to ask, who I need to ask, and what answers are important to the project. The less I know about the project, the more effective I can be. It is here that a standard approach serves best. Standard or canned questions can help identify what I need to know at a high level about the project.
Techniques such as the Agile approach of capturing User Stories are phenomenally useful at this stage of the game because I do not need to know anything about the user’s world. They can tell me in their jargon what they want the solution to deliver without worrying unnecessarily about my understanding. It is through my analysis of the collected stories that I become aware that there is much that I do not know about their world.
Either of these approaches initiates my evolution to the next level of ignorance.
Leveraging Conscious Ignorance
This state is the closest to a state of grace for me as a business analyst. While I am in this state, I know enough to ask intelligent questions. Because I am consciously aware of the myriad of things that I do not know about the domain, I can ask the “dumb” questions that an expert would not ask. I can initiate and use a question file (see the post “Conduct Requirements Interviews to Discover Stakeholder Needs” for a description of a question file) to structure and leverage my ignorance.
I can then use my question file to effectively identify project stakeholders and figure out who to talk to next. This knowledge is instrumental in allowing me to plan and prepare for the next level of requirements discovery interviews. I know enough to be able to identify interviewing topics and invite interview partners. I can develop an agenda for the interview that allows me to ferret out the various types of requirements with the appropriate techniques and capture them with suitable tools. The results of these interviews move me closer and closer to the level of conscious knowledge.
Dealing with Conscious Knowledge
As I become more and more aware of what I know about the domain, I am better able to comprehend the various users’ perspectives and needs. I can now finally understand their business and stakeholder requirements. I can help them formulate well-structured solution requirements, both functional and non-functional. Ultimately, as the requirements for the solution evolve, I can also help identify and formulate transition requirements. Because, as the business analyst, I am at the level of Conscious Knowledge whereas other stakeholders have Unconscious Knowledge, I can play devil’s advocate and guide them to a fuller understanding of their actual needs.
My role as a business analyst moves towards requirements validator as opposed to discoverer. My knowledge now should carry me — with the help of the subject matter experts, of course — beyond the documentation of the various requirement types and on to the development of test scenarios and ways of proving that the requirements will be met once the solution is delivered.
The Dangers of Unconscious Knowledge
The reason that subject matter expertise is not a prerequisite for good business analysis lies in the fact that the SMEs have a great deal of unconscious knowledge— they know too much. Because it is unconscious knowledge, they cannot readily express it. They need an outside agent to stimulate the retrieval of this knowledge. And again, because they know too much, they often have difficulty expressing that knowledge in terms that a non-expert can understand. The primary responsibility of the true business analyst is to elicit that knowledge, to trigger the thoughts, and to help the subject matter experts express their knowledge in a language that SMEs in other domains (such as information technology) can understand. To that end, I as the business analyst should never have more than conscious knowledge about the domain under study. I must never complete the learning process for this domain.
On Being a Business Analyst
As much as I can relish the sense of successfully incompleting another great learning process, I always look forward to my next project where I will once again achieve the blissful state of unconscious ignorance — albeit about a new and different domain. That is the fate of all who choose the fascinating career of business analyst. What can I say? I enjoy being ignorant about most things. The sole exception to that rule (professionally speaking — let’s not get personal here) is my knowledge about business analysis as a profession. That is the domain in which I must constantly strive for “unconscious competence” to be able to call myself a business analysis subject matter expert — aka: business analyst.
