Knowledge can be explicit as well as tacit. Explicit knowledge is something that can be easily documented, studied and transferred from one individual to another. On the other hand, tacit knowledge is knowledge that cannot be easily documented, taught and transferred from one individual to another. It includes the beliefs, attitudes, skills, capabilities, and expertise that an individual uses to perform an activity. Tacit knowledge can be difficult to transfer, as it is deeply rooted within a specific individual and the way that the individual performs specific tasks. The term ‘Tacit knowledge’ was introduced by Michael Polanyi way back in 1958 in his work titled ‘Personal Knowledge. His subsequent work, titled’ The Tacit Dimension’ focused on multi-dimensional aspects of human brain and how we store, process, filter and share knowledge with others. Basically, it boils down to ‘We can know more than we can tell’ theory. As per Michael Polanyi, tacit knowledge cannot be adequately articulated by writing down or verbal communication but can only be revealed through practice in a particular context and transmitted through social networks.
Most of the business analysis work focuses on ‘Eliciting, analyzing, documenting, verifying and validating’ the requirements emanating from the explicit knowledge base. The lack of understanding of the tacit knowledge and failure in unearthing this knowledge base is where majority of projects fail. Because your customer’s didn’t tell you (or rather they couldn’t express their requirements) and because you never knew they ever existed somewhere in their minds, the final product did not meet your customer’s expectation. This is just one scenario. The same holds true when a business analyst captures the requirements in some artifact (BRD, FRD, Use Case, User Stories etc). There is a great deal of tacit knowledge, which never gets on to those documents. It remains within the business analysts tacit knowledge base. The end result is the same i.e. final product not meeting the customer’s expectations. I believe it is imperative for a business analyst to take the lead and ensure that the requirements, hidden in customer’s tacit knowledge base, also get’s into the final product.
The below techniques will help business analyst to elicit the stakeholders requirements emanating from the tacit knowledge base and thereby delivering a product that’s build on both, explicit as well as tacit knowledge base:
(1) Close Collaboration: Collaboration and communication is the key to elicit requirements from the tacit knowledge base. Work as closely as possible with your stakeholders (Customers, SMEs, Solution Architects, Developers, Testers etc). This way a business analyst gets an opportunity to ask scenario-based questions, which might have never explored. Working in a close-knit working environment allows a much fluid communication channel across the entire team and assists team members to synthesize real-world scenarios much more dynamically.
(2) Observation: Observation is used to elicit information by viewing and understanding activities and their context. It is another powerful technique wherein a business analyst can simply observe the process participant how he/she is doing it in a particular way, what are the alternate paths, what are the triggers for taking the alternate paths, possible set of business rules hidden behind those decisions and many other ‘What-If’ scenarios.
(3) Task Analysis: This technique emerged from ‘Applied Behavior Analysis’ field. Task analysis is the analysis of how a task is accomplished, including a detailed description of both manual and mental activities, task and element durations, task frequency, task allocation, task complexity, environmental conditions, necessary clothing and equipment, and any other unique factors involved in or required for one or more people to perform a given task.
(4) Probing Interviews: Probing technique is a skillful way to understand the logic, fully understand the response, or to clear air when a response is ambiguous. There are some tried and tested analysis techniques like ‘Five Whys’, ‘Fish-Bone’ one can use for getting into the roots. The key element here is to ask the right set of questions, which aims at extracting requirements from the customers tacit knowledge base.
(5) Role Playing: Role playing refers to actually replacing a real world actor with you and actually perform a task (manually, or using an application), participate in a business process, execute an end-to-end process or process set of business artifacts. Undoubtedly the most powerful technique to get a ‘First-Hand’ experience and learn from actually doing tasks than hearing from your customers, SMEs or other stakeholders.
As more and more projects move towards an agile environments, where software is delivered with minimal documentation and in a fast-paced environment, understanding and exploring the customer’s tacit knowledge will play a much important role.
Please feel free to share your thoughts and leave your valuable comments.
Thanks & Regards
Chetan Mehta