Can Domain Expertise in isolation guarantee project success?

Can Domain Expertise in isolation guarantee project success?

In this article I will try to technically differentiate between three terms "Requirements Gatherer", "Analyst" and "Domain Expert" and will share with you, how the ambiguity between these three words can create / have created problems in the software development industry.

To start with let me first share with you my understanding of each of these roles.

Requirements Gatherer - A person who is an expert is gathering different types [functional and non functional] of system requirements.

Analyst - A person who is an expert in analyzing the complexity of systems.

Domain Expert - A person who is an expert in a particular domain.

Skills needed by each of the roles to do their tasks in the right spirit.

Requirements Gatherer

  • He should have excellent communication skills.
  • He should be a master of requirements engineering and should be equipped with the tools and best practices for him to capture both functional and non functional requirements unambiguously and quantitatively.
  • He should be able to deal with multiple stakeholders

Analyst

  • He should be an expert of modeling systems.
  • He should understand different types and levels of complexity with systems and should know the respective modeling techniques to manage that complexity.
  • He should a master of atleast one standardized modeling language , so that he can represent his understanding of the system in a form so that all the stakeholders can a single understanding.
  • He is also a person who is supposed to use engineering tools , techniques and best practices to deal with the complexity associated with complex systems.

Domain Expert

  • He should have a rich experience in his domain and hence he should be an expert in his domain. ie he should be aware of all the different types of systems prevailing in his domain along with their actors, behaviors, structural components, business logic and the relevant non functional requirements. Or in a nutshell, he should be aware of the functional and non functional requirements of different types of systems in a particular domain.

So we can see that each of these roles have different expectations and need to have different skills and expertise. It will not be fair to expect one role take care of the responsibilities of other roles as well without adequate training and expertise.

Ideally any project will need all of the three roles to be played by three different people holding an expertise in each of their fields. But in reality the situation is very different.

Most of the time we have come across software development companies wherein a single person playing all three roles or the business analyst playing the roles of requirements gatherer as well as Domain Expert or the Domain Expert playing the role of Analyst and Requirements Gatherer.

I have come across lots of pharmacists , doctors being employed by insurance based software companies as analysts although they are not trained to be experts and modeling and are supposed to gather the requirements from the customer.

Or I have personally witnessed a 200 + million dollar project going down although the company had employed the best domain experts in the business. Ask yourself why did the project fail even with the best domain expertise? The reason was although the company had taken the services of the best domain experts , but there was absolutely no analysts and analysis and because of which the company was just not able to understand the complexity of the system and hence the system failed.

This mixing and matching of these three roles can itself make the system fail.

Let us understand

"A Domain Expert might not be a good Analyst and a good Analyst might not be a Domain Expert".

I have seen companies believing that Domain Expertise can itself ensure project success with proper analysis. But people fail to understand Domain Expert is as good as the customers representative on our side and he typically faces the same problem as the customer. Domain Expert without analysis expertise is as good as a customer and he faces the same limitations as the customer.

Actually the job of a Domain Expert is to assist the analyst and the requirements gatherer in deciphering certain terms , rules related to the corresponding domain. Analysts and Requirements Gatherer needs to take the help or assistance of Domain experts to help them understand something that they cannot understand about the domain. But the critical point is the impetus has to come from the Analyst and the Requirements Gatherer.

I am not saying that Domain Knowledge/ Domain Experts are not needed , it is always good to have with them but Domain Expertise with out proper analysis and engineering can be of little use.

Or I can say "Domain Expertise" can be necessary but not a sufficient condition.

I can also say that more than Domain Knowledge/Expertise , the field of systems engineering and analysis needs a lot of discipline and engineering tools. Actually the Requirements Gatherer needs to be positioned at the customers location (Onsite) while the analysts and the domain experts should be positioned at the software development companies location (Offsite).

 
Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer

www.VPlanSolutions.co.in