 Hello and welcome to DeathWench Professional Services' online research management simulation module. Here are the learning objectives for this lecture. After watching this lecture, the audience should be able to give one example of something a principal investigator or PI can do to get internal buy-in for a research study, describe a typical conflict in research that could be solved by gathering more facts and what facts need to be gathered to solve it, give an example of a research-related problem that can be handled between research team meetings and explain your rationale as to why it can be handled between meetings, and give an example of a research-related problem that should be held for discussion in a meeting and explain why discussion is needed. In this video, first I'm going to start by giving you some information. I'm going to explain the research team management cycle and talk about a strategy I learned of how to use facts to settle debates and arguments. I'm also going to go over the management concepts of buy-in and efficiency and I'll review problem-solving strategies useful on a research team. Then, I'm going to introduce you to the online research management simulation module. Let's start by talking about the research team management cycle. When a research project starts, you put together a research team and then, in order to start getting some work done, you need to set up regular meetings. Make everyone pull out their calendars, paper or electronic, it doesn't matter, and put research meetings on them. Pick a time when everyone can come and schedule regular research meetings every week, two weeks, or month, depending upon your study's timeline for the duration of the research project. Then, faithfully hold those meetings, even if sometimes people are gone or the leader is gone and someone serves as backup leader. You might cancel meetings if there is no business when the meeting comes up, or you might end up scheduling extra meetings. But just having those meetings on everyone's calendar creates an infrastructure or a business system behind the research study which can facilitate your team producing research deliverables. When you have meetings, make them valuable. Have an agenda made from issues that come up between meetings that need to be addressed with everyone at the table. Then, when at the meeting, figure out what tasks there are, assign them, and take notes of which tasks are assigned to whom. Make all of these files available on a shared drive or in some other way so that all members of the research team can access them. Between meetings, do your assigned tasks and help other members do their tasks. If you have trouble doing your tasks, or you have a new issue to add to the agenda of the next meeting, then contact the team leader. That will make it so the leader can get her own work done, and so that issues that require everyone's attention can be handled when everyone is in the room at research meetings. Let's cover some research leadership terminology. The leader of a research team is called the principal investigator or PI for short. The PI is expected to hold and run all the meetings, but she can designate a backup for any of her tasks from time to time, just as any team leader can. The PI may actually work at any location or organization, not necessarily with other research team members, because research can be done with teams made up of members of different organizations. Because of this, the team members do not really report to the PI, so it is more like a project team or work group. Nevertheless, the PI is still responsible for the work of the members on the research team. The research team members have a term too, actually multiple terms. They can be called co-investigators, or co-i's for short, or even just investigators. As I mentioned earlier, the investigators can come from different organizations, but what is also important to realize is that they come from many different professional backgrounds. That's because different types of expertise are required for research studies, and therefore different kinds of experts are recruited for these teams, so all the tasks and areas of expertise required for the study can be covered. So what happens when a bunch of people who work at different places and are in different fields get together and try to do a research study? As you can imagine, one thing that often happens is difference of opinion. Different fields use different approaches to research, and there are often arguments about the best way to do something. Actually, these are the best kinds of arguments, because if they are done right, they produce innovative research on the cutting edge of disciplines. That's why you should really have these arguments in person at research meetings so everyone can participate and not in email, where everyone can easily miscommunicate. Then, once you are at the meeting and the debate begins, concentrate on facts. Whichever way a person is arguing for a study design, they should be able to show evidence that their way is the best. And if they can't, then the team should figure out a way to get some facts so they can make an informed decision. After all, this is a research team. You should be good at putting together enough facts so that you can all come to an agreement. I didn't come up with this idea on my own. I learned it from this book by Roger Fisher and William Urie called Getting to Yes. It's a short book, but it teaches you the basics of negotiation. One point they explained is that getting facts on the table that all sides agree are credible is one way to reduce the area of debate. What I learned from this book has really helped me work on research teams, so I am recommending it to you. Let's shift gears away from negotiation to another important concept in research team management, and that is buy-in. Those of you who are watching who are teenagers out there, let me ask you honestly. Do you really believe it if your parent says that doing homework builds character, and that you really need to know math to have a positive future? Okay, well, I didn't believe it either. And guess what? I had to take calculus in college. Why did that happen? I think Teenage Me speaks for many teenagers out there. We just didn't buy it. When you are a PI and you have a lot of teenagers, or I mean investigators, on your team, you have a similar challenge. But it's harder because investigators are smarter than teenagers, well, usually, and there are more of them, so they can really gang up on you. Therefore, whenever you design research and you write your research protocol, you need to be at the meeting to discuss big changes. You can't do it over email. By making big changes only in the presence of and with the participation of other team members, can you create transparency in the team and build buy-in that way? You want to create other ways of being internally transparent to the team. For example, Zotero is a free reference library software that easily allows you to share libraries across geographically disparate team members. If you all happen to work at the same organization, you can set up a shared folder on a shared drive for storing documents like meeting agendas and notes. But if you are not at the same organization, you might choose Dropbox or some other online application to help you share these files to increase transparency and buy-in. Why are we doing all this extra work of setting up shared libraries and folders and hashing out difficult issues and meetings? Because we want buy-in, and the reason we want buy-in is we want to build trust. Mixed messages compromise trust in academia where people are often trying to backstab each other to get ahead. Honest mistakes are not always seen that way. By sharing documents and other items across the team, you can guard against this mixed message phenomenon. That way, if there are mistakes, the team members can feel emotionally safe and simply assume that it was a mistake, not that someone, especially a team member, was trying to backstab them. We have transparency because we want buy-in, and we want buy-in because that leads to trust. And why do we want trust? Well, other than the fact that it is a very wonderful feeling to actually trust your colleagues, the reality is that the more team members trust each other, the more efficient you can be. That's where my message should hit your research bottom line. When there's trust, team members feel safe when acting independently and know when to go back to the group for guidance so they can get more done. The infrastructure of the meeting cycle allows team members to know there is a forum where difficult issues can be discussed. So, even if there is some sort of problem, such as a team member is struggling with a task, there is a way to involve the team in the solution. After all, the research study is everyone's project, not just the PIs. So, to build trust, we want buy-in from both internal and external stakeholders. To get internal buy-in, we can coordinate structured meetings, keep track of team files and share them, ensure that everyone is playing their role on the research team, and maintain strong lines of communication. But, you have to please external stakeholders too, such as the different bosses of the people on the research team. One way to get external buy-in is to share certain official documents with certain external stakeholders. For example, you might share notes to a meeting where you discussed an issue being brought up by an external stakeholder. It's also good to invite targets of your study to serve as investigators. In other words, if you are trying to study the efficiency of an emergency department, you really should have an investigator from that emergency department on your research team. That person will not only be able to give you local knowledge about their department, you could not get otherwise, but if you share your research files with them and gain buy-in, they can become a real champion for your research study and help in your bid to get buy-in from everyone impacted by the research. Before we turn to the simulation where we can think more about buy-in, trust, and efficiency, let's look at some common problems research teams face and some potential solutions. Here's a common problem, disagreements about some element of the design of a study. Imagine your research team wanted to do an anonymous survey of athletes to find out how common it is for them to use illegal substances. Since this is a touchy subject, response rate can be an issue. You plan to do the survey among members of a gym with which your team has partnered and some in the team think your survey would get a better response rate if done on paper in person at the gym and others think that a better response rate would be obtained if you emailed a link to the online survey using the gym membership database. Who knows who is right? Well, one thing is for sure, I don't know who is right. It's because I lack the facts I need to make that decision. One way we could get facts to make this decision is to get a pilot study approved where the team would only email the link to 100 email addresses and spend one day at the gym collecting data on paper. Then we'd have two actual response rate numbers we could compare and then decide how to spend the rest of our resources. Something that would be simpler to do is to simply go talk to people informally going to the gym to see which way they would be more likely to answer the survey. And there are other answers to this problem, but they all center around gathering more facts to help the group come to a group decision. Anyone who has done research before knows that it is an error prone activity and there are often unexpected changes of plans. Take this situation. Let's say the PI of a research team negotiates a lab contract for the study then sends an investigator to go sign it, but when the investigator sees the actual contract she learns it has increased from what the PI negotiated. Let's say the lab tells her upfront that their expenses went up and they had to increase the contract. So what should the investigator do? Her assignment is to sign the contract and if she doesn't the study will be delayed. But the contract isn't what the PI thought it would be. So what's the right answer? After all my research experience I tend to have a more laid back attitude. Although it would be best to actually call the PI and figure out what to do on the spot. When I'm the PI I typically choose to tell the investigator not to do the task and instead wait for the next meeting where we can all discuss it. If the increase was not much meaning it would not really affect the budget or the rest of the study maybe I would tell the investigator to sign it. But if it impacts the study the team should really be a part of the decision if the timeline is delayed. There are many possibilities that can be explored including continuing to negotiate with the lab leaders to see if the price increase can be reduced just for our project. Like with working on any team research teams often face the challenges of miscommunication and interpersonal conflict. Here is an example of a common communication problem. Imagine that Dr. A is on a research team at an organization and she is really happy to learn that her old friend Dr. X just got hired there and is being put on her research team. In fact the PI knows that Dr. A and Dr. X are old friends so the PI asks Dr. A to formally invite Dr. X to join the research team. But when Dr. A goes to have lunch with Dr. X she learns that Dr. B, another investigator on the research team has already invited Dr. X to the research team. So what's going on here with all these mixed messages? Even though this is an interpersonal situation it is still helpful to gather more facts. Dr. A should gracefully welcome Dr. X anyway. In fact over lunch Dr. A can ask Dr. X about the interaction with Dr. B. Maybe the PI simply forgot that Dr. A was tasked with inviting Dr. X and not Dr. B. In the end Dr. A, Dr. B and the PI should iron all this out. It's unlikely that anyone on the team meant any harm and no one wants to harbor hard feelings when an honest mistake was made. A final common problem covered in this lecture that research teams face is splitting up work in a way that is efficient and helps get the work done. Let's think about Dr. A and Dr. B again. Imagine they are on a research team and are tasked with calling 50 clinics and asking them if they'd be willing to refer their diabetes patients to the study they are doing. Drs A and B agree to split up the list and make all the calls but this is logistically difficult because they work at separate locations and really only interact at research meetings. How might they approach splitting up the work given this situation? Well, here's where setting up transparency can be an advantage. If you run the research team out of a shared drive like Dropbox, then a folder or directory can be made just for this task and Drs A and B can use that to keep track of their work. They might make a shared spreadsheet with the list of clinics and phone numbers on it and then mark up who will call which clinic and when they do talk to them what the clinic says. However they choose to split up the work, the meeting is where they should plan this. In the meeting they can decide on where they will be sharing their work electronically and how they will signal to each other which clinic they are calling and how they will document what the clinic says. Since their decisions impact the rest of the group, it's nice to have these discussions in front of everyone at the meeting so other team members can give advice to Drs A and B on how to split up the work and so everyone is on the same page with what is decided. Alright, let's shift gears now. Let me introduce you to the online learning module. This learning module allows you to consider three scenarios experienced by a laboratory research team and strategize ways to solve problems in those scenarios. At the end of each scenario is an essay question about the scenario. This is the entry page for the module. Above you will see this video which teaches about the managerial behavioral skills that this module is intended to develop. The video also provides an introduction to the module. Note that below the video are links where you can download the slides in the script. That way if you prefer to read rather than watch the video you can do that. The introductory information is also on this page below where there is an overview of the module. This module centers around a research team at a hospital system doing a laboratory study. On this page information about the research team members is presented along with links to the three scenarios. At the top of each page in the module is a menu to help you navigate within the module. The first entry introduction brings you to this page. Then there are three scenario buttons and the last button is for the module completion page. Let's go to the first scenario. Notice this menu is on the top of the scenario pages as well. On the scenario pages after a short reminder of the instructions at the top a specific scenario is presented and is followed by the simulation which provides information about what each member of the research team is thinking and saying. At the bottom of the scenario is an essay question about the scenario intended to allow you to imagine yourself using your new research management skills. You can practice the information you learned by answering the essay question. A rubric is provided to guide you. After completing all three scenarios you are invited to go to the module completion page by clicking on the button on the menu. On this page there will be a debriefing video helping you process what you learned from the module. The final instructions are listed along with payment instructions where you can pay for your certificate of completion and feedback if you want them via PayPal. Whether you pay or use the module for free we'd appreciate your feedback. Please fill out our post module survey. You'll also see that the module policies are on the course completion page and if you have questions about the module you can click here to email us. And if you want to share the module with the world via Twitter go ahead and click on the tweet at the bottom of the page and let us all know you completed it. This module is to help professionals who are new to working on interdisciplinary research teams gain skills in managing research and working together on a research project even if they may have very different professional and personal backgrounds. It creates a fictitious research team at an imaginary medical system then asks the learner to actually take the perspective of each team member in order to understand the issues and practice addressing the challenges. It is aimed at working professionals who want to serve on interdisciplinary research teams. What this module encourages is cognitive rehearsal. By imagining each member's perspective the learner can practice in her mind or cognitively rehearse how she might respond where she a member in the scenario. Research has shown that learners who undergo cognitive rehearsal to gain situational behavioral skills are able to gain these skills faster and more comprehensively from this approach. Curricula aimed at teaching behavioral skills to professionals in healthcare have successfully used modules that incorporate cognitive rehearsal especially in the nursing field. The setting for the module is Holiday Medical Corporation which is an abbreviated HMC which is a fictitious healthcare system in the Midwestern United States. Dr. Pappy is a pathologist and director of the biggest HMC laboratory which serves Holiday General Hospital. The issue is that recently some of Dr. Pappy's laboratory technicians began alerting him to some unusual lab values. Dr. Pappy is worried about the quality of cholesterol level testing in this lab so Dr. Pappy put together a research team and wrote a quality assurance quality improvement research protocol to study the problem and come up with a solution. In the research protocol patients who are undergoing cholesterol panels at Dr. Pappy's lab are offered the ability to participate in a study. If they consent, their specimen is split and analyzed not only at Dr. Pappy's lab but by a commercial lab called Labrite and another HMC lab at a different location run by Dr. Virus. This brings us to the learning objectives for the entire module. At the end of this module, the learner should be able to describe a situation where a personal opinion about a person or type of work might get in the way of problem solving on a research team and offer a solution, describe a situation in which the way a business process runs can cause interpersonal problems on a research team and offer a solution, identify three ways team members can provide each other support when serving on a research team, list three traits of a good research team leader and explain how these traits help the research team leader be effective and name one strategy to improve the effectiveness and efficiency of research meetings. Okay, now let's meet the research team. First, we have the PI of the study, Dr. Pappy. He's a world renowned researcher and an experienced laboratory director who runs the biggest lab at HMC. Next, we have Dr. Statz. Dr. Statz is a statistician at a research center at HMC and she's offered to help the team. She's trying to build her skills in epidemiology and study design and the best way to do that is to participate on interdisciplinary research teams like Dr. Pappy's. Here is Dr. Virus. She's friends with Dr. Pappy and directs a different laboratory at HMC. Unfortunately, there are a lot of issues surrounding Dr. Virus. She's had health problems and her boss, Dr. Grouch, is very mean. Dr. Virus' lab is one of the labs involved in the study along with Dr. Pappy's. Next, we have Junior, the pathology resident working in Dr. Pappy's lab. Junior really likes the laboratory environment and he's happy to be on the research team so he can get experience and land the fellowship of his dreams. Finally, we have Big Labby, the CEO of Labrite, the commercial lab involved in the study. Big Labby is not officially on the research team but attends meetings once in a while if the group has questions. Big Labby is very excited about the study because this is the first time Labrite is partnering with HMC on a study and he wants to nurture this new relationship to hopefully expand into the research sector. This is just a quick introduction to the research team in the scenario. You will notice that there is more information about their backstory on the overview page of this module. If you read more about the research team, you will have an easier time taking their perspective and be able to use cognitive rehearsal to your advantage. Now, let's turn our attention to the three scenarios in this module. In scenario one, we face a potential problem at Labrite. At a research meeting, it is found that Labrite results are missing in 20% of the tests. Is this the end for Big Labby? Or will the research team come together and solve the problem? In scenario two, all eyes are on Dr. Virus. At a research meeting, it is revealed that Dr. Virus' lab has only processed 15% of their specimens when the other two labs are up to speed. And Dr. Virus is full of excuses. Will the research team reject her excuses? Or will they give her a helping hand? In scenario three, recruitment is behind and since that's Junior's job, everyone is looking at him for answers. Will he get kicked off the team? Or will they rally around him and help solve the recruitment problem? Alright, now it's time for you to weigh in on how this research team should solve their problems. To use the module, first, finish reading the background material on this page. It will provide you more information about the research protocol and the backstory of each of the team members and how the team was formed. Then, once you are ready to complete the scenarios, click on each scenario page and interact with the multimedia on the page to learn about the scenario. At the top will be instructions about the scenario followed by a scenario description, goal, and learning objectives. Next, the simulation will provide information about each of the research team members. It will provide their thoughts about the scenario and what they say in the meeting about the scenario. If you prefer listening to reading, you can click on the audio to hear what they are thinking and saying. Once you are done with the scenario, you can help yourself process what you learned by answering an essay question about the scenario. Please observe the rubric below the essay question. If you choose to actually turn in your essay question for a nominal fee, your essays will be graded by a real person and feedback given to you on a rubric. You will have the opportunity to do this at the end of the module, so please make sure you save your essay answers so you can provide them at the end of the module for grading. Finally, after you finish all three scenarios, the last stop is the module completion page. At the top, you will see a debriefing video. Watch this, then when you are done, feel free to request your certificate of completion or feedback under the payment tab, where you will be given an opportunity to complete our post-module survey. Even if you do not purchase anything, please fill out our survey so we can learn how to improve the module. It is about 40 questions, and will take you about 10 minutes. Thank you for your interest in DPS's Research Management Module Simulation, and we hope you enjoy your learning experience.