How Our NeuroDevNet Team Used Systems Thinking to Improve Our Production of Research Summaries
by Anneliese Poetz
Knowledge Translation. Anneliese has experience writing plain language research summaries for policymakers, parents and teachers at the Canadian Language and Literacy Research Network and, in her most recent work for the National Collaborating Centre for Infectious Diseases, she facilitated national stakeholder consultations, and developed stakeholder-and evidence-informed products to improve public health practice. For more on Anneliese and her work click here. This post originally appeared on the KNAER-RECRAE Blog and is reposted here with permission.
I recently had the pleasure of being able to present at the recent Canadian Knowledge Mobilization Forum (#CKF16) conference in Toronto, Ontario. It was a 7-minute presentation entitled “Systems and Processes for Knowledge Translation” and focused on one of the examples of how I use systems thinking to inform my work in Knowledge Translation (KT).
Several years ago, I met a business analyst who informed me that what I was doing in my job in the field of KT was essentially what a business analyst does: use stakeholder input to inform the design (and/or re-design) of products and processes. When you think about it, everything we do in KT is either a product or a process. The products I worked on included evidence-informed tools for health care practitioners to apply to their work, and guides for researchers to help them “do” KT. One of the processes that we needed to improve was for our production of clear language summaries called ResearchSnapshots.
Wondering what the difference is between Knowledge Mobilization, Knowledge Translation, and other like terms? Visit Gary Myers’ KMbeing blog post and join the conversation on KMb: Definitions & Terminology.
If you look at slide #6 in the above presentation, you will see a framework that outlines the key concepts in business analysis, according to the Business Analysis Body of Knowledge (BABOK v.3). These are: 1) Need 2) Change 3) Stakeholder 4) Solution 5) Value 6) Context
Each of these is of equal importance, and all must be represented. One of the things we did wrong with our initial process for the ResearchSnapshots was that we transferred the existing process (and writing staff) used by York’s KMb Unit without consideration of the differences in context within NeuroDevNet.
One of the ‘tools’ within the field of Business Analysis is a methodology called root cause analysis. We conducted a root cause analysis in order to pinpoint what the root of the problem was, and create a targeted solution. We discovered the problem was that the writers used by York KMb’s Unit, although highly skilled in clear language writing, had social science expertise but were asked to summarize research papers that were basic science and clinical science based. The researchers complained that they had to rewrite most if not all of the content, and it was a lot of work for them to do so. The result was that we achieved customer satisfaction (buy-in) among the researchers for the new process.
What we did to improve the process was to first identify all the stakeholders directly and indirectly affected by the process. Then we gathered information about their needs (often in the form of the complaints we’d received from researchers) with respect to the process, which were then transformed into ‘requirements’. These requirements informed the re-design of the new process.
The process had to be easy for researchers, and create value for the Network. Since the projects within the Network were so diverse and often specialized, it would have been too difficult (and maybe impossible) to find writers who were content experts. So, the new process begins with the researcher nominating a paper that was produced as a result of one of their NeuroDevNet funded projects, along with one of their trainees (students) who is expert in the content area. Then, we provide training and support toward the production of a clear language summary of their paper that is ready for final review and sign off by the researcher. In this way, it is easy for researchers because they only have to make minimal edits to the draft, and it creates value for the Network not only because of the clear language summary that is produced but the transferrable skills that the trainee acquires.
Let’s break down how this method reflects ‘systems thinking’:
1) A system is composed of parts. The first thing we did was map out the stakeholders and where they were situated within the system (see slide #9).
2) All the parts of a system must be related (directly or indirectly). We mapped out the stakeholders as related, directly or indirectly, to the customer service issue (or ‘incident’).
3) A system has a boundary, and the boundary of a system is a decision made by an observer or a group of observers. The ‘system’ was what facilitated the execution of the process for creating clear language summaries (ResearchSnapshots). In other words, the boundary of the system was the affiliation of researchers as part of NeuroDevNet, and research papers to be summarized were those produced as part of NeuroDevNet funded research projects.
4) A system can be nested within another system, a system can overlap with another system. The ‘system’ for producing ResearchSnapshots within the KT Core with one researcher is nested within the larger ‘system’ of the NeuroDevNet pan-Canadian Network of researchers and projects.
5) A system is bounded in time, but may be intermittently operational. A system is bounded in space, though the parts are not necessarily co-located.We engage with researchers to co-create ResearchSnapshotsat the time that we receive a service request, usually after a researcher has published a new peer-reviewed paper. These requests are sporadic depending on the frequency and pace of publications arising from its pan-Canadian NeuroDevNet-funded projects.
6) A system receives input from, and sends output into, the wider environment. We receive requests but we will also offer services if we see an opportunity. Once the ResearchSnapshots are finalized, they are made available on the NeuroDevNet website.
7) A system consists of processes that transform inputs into outputs. The process for clear language writing of ResearchSnapshots is one of the processes that exist within the KT Core, that transforms inputs (peer reviewed publications, clear language summary drafts in word) into outputs (finalized draft of clear language summary, formatted onto ResearchSnapshot .pdf template, formatted for accessibility).
8) A system is autonomous in fulfilling its purpose. A car is not a system. A car with a driver is a system. Similarly, the KT Core as a department within NeuroDevNet is not a system. The KT Core with a Lead, Manager and Assistant, is a system.
As a systems thinker, remember that a system is dynamic and complex, and that information flows among the different elements that compose a system. For example, information flows among the KT Core Lead, Manager and Assistant. A system is a community situated within an environment. For example, the KT Core is a system situated within NeuroDevNet, and as a result, information also flows more broadly between the KT Core and NeuroDevNet’s community of researchers. Information flows from and to the surrounding environment, for example, the KT Core posts its finalized ResearchSnapshots publicly on the NeuroDevNet website.
The field of Business Analysis has identified (and published in BABOK) a common sense framework and practical methodologies, which I believe can advance the field of KT towards more meaningful and useful products and processes that are responsive to the systems in which they are intended to be used.