In this third part, we examine how data is managed (and has to be) as the process of research gets going. We also look at the challenges in specifying information requirements for any research and what lessons can be learnt from concurrent engineering

There are two kinds of data – one that naturally accrues to an organization as a result of its business operations captured through transactions and stored in some format in some database and other being what is gathered by an organization for a specific purpose or purposes. Let me add that the second may happen quite regularly as organizations need to figure out so many aspects of and in this complex world. What follows relates to data that I have described as the second.

Students who have undertaken some research, not necessarily through a PhD, could have come across the term ‘research design’.

The Sacred Heart University Library has a fine definition: “The research design refers to the overall strategy that you choose to integrate the different components of the study in a coherent and logical way, thereby, ensuring you will effectively address the research problem; it constitutes the blueprint for the collection, measurement, and analysis of data. Note that your research problem determines the type of design you can use, not the other way around!” (https://library.sacredheart.edu/c.php?g=29803&p=185902). By the way, this is an excellent paper to read for any student from any stream. There are many who distinguish between research design and research approach but my purpose here is different – it is on data. All definitions however address the question of data gathering and collection. Let me mention in passing that there is primary data (what you gather yourself) and secondary data (already published data). It is always advisable to examine secondary data first to check if it can exhaust the research requirements, given that both public and private organizations are capturing so much of data about so many things. It will even help in identifying what further needs to be gathered. Either way, it is important to identify sources of data and techniques of gathering information, including formats. Most people fail to recognize the importance of formats but ignoring will lead only to embarrassing results.

It is true in most cases if not all that all data requirements cannot be clearly spelt out at the inception of the research, however exhaustive the attempt to define. This raises the dimension of iterations. I am suggesting that there is benefit in evaluating the practice of concurrent engineering as a possible technique, not as it is because the terrain is different but the approach.

The most important point about concurrent engineering is that it “was developed solely through engineering practice rather than theoretic ideas” (https://fractory.com/concurrent-engineering/). In engineering, it addresses product development and related engineering. To borrow more from the same source, “Concurrent engineering or simultaneous engineering is a discipline of integrated product development whereby all the life cycle aspects of a single product are considered simultaneously right from the start. Even at the conceptual phase, engineers are already working on solving everything possible that comes after the product launch. (https://fractory.com/concurrent-engineering/)

The idea behind CE is to reduce the risk of designing a product that cannot be ‘engineered’. Design and Engineering work in tandem right from the beginning to minimize such a probability and improve the chances of producing the designed product, clearly involving a series of iterations. It is a matter of debate whether such iterations should be related to some milestones or left open depending on developments. Engineering can keep informing the design of its feasibility while design can keep throwing a challenge to engineering to build. Naturally, all these involve related R&D in materials, materials engineering, production systems not to mention marketing. In many companies that practiced CE, Design and Engineering teams were on the same floor to facilitate easy exchange of relevant communication.

In my view, this approach, certainly not free from pitfalls, adopted in the right spirit can be beneficial in research projects, especially which are spread over time and involve data from multiple sources, with all that this implies.    Now look at research and the related data collection, which could be qualitative, quantitative or a combination of both. While both have their respective roles to play, qualitative data poses significant challenges. As Elis Paradis observe, “Qualitative research is often employed when there is a problem and no clear solutions exist”, while discussing the selection of data collection methods (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4857496/).

In an article titled ‘The case for iteration in qualitative research design’, Nhu Le and others argue why iteration is important. Iteration means “incorporating what you learn at one point in the research into the remainder of the research, instead of following rigid linear steps. It is key to generating richer and more useful qualitative data” (https://medium.com/idinsight-blog/the-case-for-iteration-in-qualitative-research-design-e07ed1314756). As they explain, “During iteration, we make use of data captured in almost-real-time to update and improve on our theory, methods, and sample in pursuit of a more complete understanding of a context or phenomena.

The unpredictable nature of qualitative data feeds the iterative process. Unexpected information that emerges during data collection can be used to adapt your methods and sample to better capture and explore further insights. For example, you can incorporate into the interview guide a new probe that worked particularly well at eliciting a rich response, or you can explore a new hypothesis generated by a response in future interviews or observations” (https://medium.com/idinsight-blog/the-case-for-iteration-in-qualitative-research-design-e07ed1314756). Some researchers argue the case for data collection to be completed before analysis begins to reduce bias, it is possible to make a case for the opposite while reminding ourselves constantly to beware of confirmation bias – looking for data to confirm what we want. This is a real risk but like any risk can be factored in with safeguards. It is naïve to conclude at the beginning itself that all required data has been collected. Let me simply state that there are many examples of missing data and how it vitiated research.

This is what we can learn from CE although the context is different as is the goal. Prachi Srivastava of The University of Western Ontario and Nick Hopwood of The University of Technology, Sydney, say, in their paper “A practical iterative framework for qualitative data analysis” in the International Journal of Qualitative Methods, that “The role of iteration in qualitative data analysis, not as a repetitive mechanical task but as a reflexive process, is key to sparking insight and developing meaning” (https://www.researchgate.net/publication/215472971_A_Practical_Iterative_Framework_for_Qualitative_Data_Analysis).

Anyone who reads on CE will discover that it is a difficult terrain and has encountered many problems. However, its basic principle of an integrated approach such that the risks in product development are minimized can be applied to research and related data. Not a blind imitation but an intelligent adaptation.

Takeaways

Specifying information requirements of any research cannot be complete in the beginning

Research design plays a crucial role

Concurrent engineering can help in a research project, if used well