The question of how essential domain expertise is to a business analyst is a recurring debate in the BA community. One school of thought maintains that domain knowledge is not critical. A skilled BA, the thinking goes, can walk into nearly any project situation and do an effective job of exploring requirements, relying on previous experience and a rich tool kit of requirements techniques. The counterargument avers that an analyst who has deep subject matter knowledge can be far more effective than a more general practitioner.
I have experienced both situations, from inside a company as a regular employee and from the outside as a consultant. This article offers some thoughts about when domain knowledge is valuable, when it’s essential, when it’s not necessary, and when it can actually pose a risk.
Domain Experience Matters!
I began my career as an organic chemist, working as a photographic research scientist at Kodak for a few years before I transitioned into full-time software development. Then I developed applications for other scientists and technicians in the Kodak research labs. I found that my experience in photographic science was highly valuable as I worked with researchers to understand their requirements for the software my group developed.
I knew the scientists’ vocabulary and practices. This gave me a context to understand what they were trying to do and to interpret their stated needs. I could ask questions at a deeper level than if I didn’t know anything about chemistry or photographic science. I could anticipate many of their needs, because they were doing work similar to the kinds of work I used to do. I could propose capabilities that users might find valuable but hadn’t thought of on their own. I was able to identify, and challenge, some of the assumptions my customers might be making. In addition, I already had much of the tacit knowledge that doesn’t even come up in discussions between users and BAs who are unfamiliar with the problem domain.
Also very importantly, I had credibility with my customers because they knew of my background in their field. They didn’t have to explain basic concepts and terminology to me. I knew how the scientists liked to work, which was helpful in designing user interfaces they would find acceptable and efficient to use. They trusted me to understand their needs more than they trusted the people from other corporate IT departments who came in periodically to develop applications.
And all this paid off. I—and several other members of my team who also had scientific backgrounds—worked effectively with our users to understand and meet their software needs.
Any time an employee transitions from the user role into a BA or software developer role, you can reap the benefits of this kind of deep business domain knowledge. This is especially valuable for specialized technical or business fields, where it could be difficult and time consuming for a generalist BA to get up to speed. It’s a powerful advantage—perhaps even a necessity—in regulated industries, where systems must comply with many business rules, including corporate policies, industry standards, regulations, and laws.
However, therein also lies a potential trap. Whenever a BA is thoroughly versed in the subject matter, you need to consider the possibility that her experience is not entirely current or relevant to the new project. If too much time has elapsed since she was a practitioner, important aspects of the business or industry might have changed.
A BA in that position must resist the temptation to assume she knows more than the users. She might even think she doesn’t need to consult with users about certain aspects of the requirements exploration, because she already knows what they need. Having BAs suggest system functions during elicitation often adds value, but they should always validate those ideas with actual user representatives.
An understanding of the problem domain helps a BA to explore nonfunctional requirements more thoroughly. Customers might not think to present information about constraints, external interfaces, and the many quality attributes that have such a big impact on system success. A knowledgeable BA will know when particular quality attributes, such as safety, security, and robustness, are especially critical and make sure those areas are addressed.
In sum, business domain experience and knowledge provide a valuable asset for a business analyst, but it can also pose a risk if the BA overrides customer input based on her perception of her own expertise.
Domain Experience Doesn’t Matter!
The counterargument maintains that a skilled and experienced business analyst can be effective on most any kind of project. While an understanding of the problem domain can be helpful, it’s not essential, because solid BA techniques can work on any project. The BA will learn what he needs to know about the domain as the project goes on.
This is likely true for many types of information systems projects. There are a lot of similarities in the approaches a BA will take on diverse IT projects. The specific details and context for a particular project don’t have a huge impact on the requirements approach. If you’re a BA in a corporate or government organization, you’ve probably already acquired some domain knowledge through interactions with your business counterparts on previous projects.
However, other factors come into play if you’re an outside consultant or a business analysis consulting company. If you decide to acquire deep knowledge in a particular domain to appeal more to prospective clients, you might narrow the scope of potential engagements. Is that a good strategy for you or your company? Recognize that you’re committing yourself to always finding new work opportunities in that same domain. On the plus side, you can probably command higher fees if you’re an expert in a relevant domain.
The importance of domain knowledge depends on the kind of work you perform as a BA consultant. Obviously, domain experience helps a great deal if you’re a practicing BA, coming into a client organization to work directly with their staff on requirements development. But not all BA work fits in that category.
Even though I’ve called myself a “consultant“ for more than 20 years, most of the work I’ve done involved delivering training on requirements development and management. I’ve taught nearly 300 classes on requirements to companies in a wide range of business areas and for local, state, and federal government agencies. Obviously, I cannot be an expert—or even minimally experienced in—all those different areas.
But it doesn’t matter! Everyone is wrestling with the same kinds of requirements problems: how to identify and engage with stakeholders; the right questions to ask; how to represent the knowledge you acquire through elicitation discussions; prioritizing requirements; and all the rest. The requirements process is much the same whether the company is working on tax-preparation software, firmware to control an air-conditioning system, or anything else.
This insight meant that I didn’t need to acquire deep business domain knowledge to be able to help a wide variety of clients in my role as a consultant and trainer. In fact, having worked with so many different companies allows me to take techniques that are effective in one domain and pass those along to clients in other fields. I don’t know a whole lot about any specific domain, but I know a little bit about many of them now.
I do try to localize the examples in my courses to be as meaningful as possible to each audience. However, it’s not practical to maintain many variations of each of my training courses to suit the needs of audiences in specific domains. If I were to specialize, I’d immediately lose a lot of potential business. Fortunately, I’m pretty good at coming up with examples on the fly and providing suggestions to help any audience adapt the requirements practices I advocate to their specific situation.
Business analysts who have worked in multiple fields have a lot of experience with diving into new projects and quickly getting up to speed. They know the right kinds of questions to ask and the important areas to explore during requirements elicitation, regardless of the specific nature of the project. They’re skilled at facilitating group sessions, coaxing essential information from the company’s subject matter experts, and representing that knowledge in ways that will speak to all the project stakeholders. A senior BA can synthesize his experience with diverse projects to help customers reach a rich understanding of requirements efficiently, picking up the domain knowledge he needs along the way. Though a company might advertise for a BA with extensive experience in, say, banking systems, you might assess your skills to see if you could do the job effectively even without that specific experience so you can make your case to the hirer.
So, Does Domain Experience Matter?
The answer—as is so often true in software development, business analysis, and life in general—is “it depends.” A BA with thorough knowledge of the problem domain can do a more insightful job of exploring requirements and assessing the impact of a new system and process changes. If you’re hired into an organization as a BA consultant to work on a project, the more you know about the kind of work they do, the quicker you can get up to speed and the more efficiently you can work. If you don’t have extensive experience in the field at the outset, don’t be afraid to ask questions so you can learn the terminology and context rapidly. However, don’t exaggerate your knowledge in the business domain in the hope of landing the job. Maybe you could bluff your way through, but I’ve always found it best not to pretend I was an expert in some field if I am not.
A skilled BA can add value even on projects for which they lack deep domain knowledge. Asking what might seem to be naive questions is a great way to discover information that no one close to the problem area ever thought to bring up. The BA won’t make the same assumptions that people who have worked in the domain for years might hold. Customers who think they already know everything can be pleasantly surprised when a BA who doesn’t share their extensive background opens their eyes to fresh understanding. And of course, a BA can bring structure, process, and thoroughness to requirements activities even without knowing anything about the business.
If your primary role is to provide services like training, coaching other BAs, process and template development, and perhaps establishing a business analysis center of excellence, domain knowledge is not vital. Having expertise in a particular area will help you sell yourself to a potential employer, but practically speaking, it probably doesn’t matter much.
Just watch out for the twin traps I mentioned earlier. Beware of narrowing your prospective employment opportunities through specialization. And don’t assume that your previous domain experience means you know more about the problem than the customers do. You probably don’t.
Author: Karl Wiegers, Principal Consultant at Process Impact
Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of numerous books on software development, most recently Software Requirements, 3rd Edition (with Joy Beatty). He’s also the author of Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, a memoir of life lessons, and a forensic mystery novel, The Reconstruction. You can reach him at ProcessImpact.com or KarlWiegers.com.