A friend asked me this question recently, and my reply to him was, “No, in my opinion.” This is because project management skills can be portable and cut across multiple domains. However, the main reason for my answer is that communication is the key regardless of which domain one needs to deal with people, and there are processes.
This topic has been around for decades, and two schools of thought cut the answer in two ways. First, it depends on how one argues and their experiences on either side of the court. Having domain knowledge is beneficial but not essential in determining if one can be a project manager. Let us look at the definition of domain knowledge.
Domain knowledge is knowledge of a specific, specialized discipline or field, in contrast to general (or domain-independent) knowledge. The term is often used in reference to a more general discipline — for example, in describing a software engineer who has general knowledge of computer programming as well as domain knowledge about developing programs for a particular industry. People with domain knowledge are often regarded as specialists or experts in their field. — Wikipedia.
Advantages of having Domain Knowledge
Being a project manager with domain knowledge does have its advantages.
Project planning — you will know what to look out for and what activities you need to perform. In addition, you know the sequence of events and critical milestones you need to be aware of. You might even be able to do all these at your fingertips without involving anyone in your project team.
Risk Management — you understand the potential risks that your project is facing. Knowing all these help in mitigating them and planning for contingency action shall any of them get triggered.
Work Breakdown Structure — you can easily break down the activities into work packages. This makes it easy to tag the time, resources, and other considerations to each work package to sum it up.
Domain Language — contains domain-specific lingo and terminology that you can easily understand. There will not be any misunderstanding on the use of specific context since everyone could be on the same page, and there will be at least no assumptions about the short forms used throughout the project.
Domain Knowledge is not Everything
In my experience, two occasions highlighted that domain knowledge is not critical. In contrast, the broad experiences that we had helped to bring a different perspective to the situation. In one of the situations, one of my customers runs a locally famous food industry. When we were engaging him and his team for a digital transformation project, he commented that he does not require us to have the domain knowledge of his industry. On the contradictory, he mentioned this to us, “Ask me anything about my business, and I can share it with you. However, I hope you can look at how we can do things differently from your perspective, not from this industry.” What he seeks and appreciate is the views of someone who do not bear the bundle of being in the industry for decades. One starts to get confined in that space and is reluctant to explore new things and change.
In another example, I was the PM for a project with a local government agency, running a project that dealt with Facial Recognition. It was in 2008 and was still a new technology in Singapore, and I did not have the domain knowledge. However, I am willing to get my hands dirty and be physically involved in any aspect of the project. Since I am new to this area, I am eager to communicate with different stakeholders, dare to ask people questions, and say, “I don’t know, please share more with me.”
In that project, I see that having the domain knowledge itself is insufficient to contribute to the project’s success. So I realized that I needed to pick up and understand areas in Lighting, Networking, Infrastructure, Imaging, etc., to deliver the project successfully to the customer. It took us approximately five years with the customer to break away from being fixated on the technology aspect, and we started to gain repeatable success in our deployment. Beyond technology, other factors such as Human Behavior, Human factors, Anti-Terrorism, and others contribute to the successful implementation.
Well, you can argue that all these make up the components in this domain of facial recognition. However, before people become more aware of such related factors, many focus on claiming that their technology is the best. This article is on domain knowledge, and I keep this example in the current state.
Break the Limit
This topic is usually heavily debated; depending on your personal experience, you will argue for what you are experiencing. For example, I am experiencing situations where domain knowledge is not essential and doesn’t affect how I can run my project. Customers continue valuing my input and trusting that I can do the job for them. However, I believe there would be situations where I need domain knowledge before I can effectively run the project.
Regardless of our experiences, we ought to consider our situation at that instant before we take up the offer to run the project. Don’t let our past experiences limit us in how we approach things. Break the limit.
Finally, what would I do if I needed to have the domain knowledge to run a particular project? Well, I will engage a consultant to get advice on that gap.