 Hello, my name is Philip Tarrant. I'm the research data management officer for Arizona State University. My role at the university is to lead in partnership with the ASU library and other university units, our initiatives to expand and accelerate our research data management infrastructure. Be effective in this role. I also collaborate with colleagues at other institutions to explore broader research data management efforts, share ideas, and learn from each other. Our research is conducted in many ways. But if we think of the conceptual research cycle, there are several phases. This graphic is one way of viewing the progress of a research study from its early beginnings through to a successful conclusion. In the early ideation phase, it may be just an idea, possibly based on previous research. During this phase, that idea is developed and potential grant opportunities, collaborators and funding sources are identified. That formulated idea is then developed into a compelling proposal that includes collaborators, plans, and budgets, eventually being submitted for funding. If the proposal is awarded, the investigator is able to pull the project team together and conduct their research. And once the study is complete, then all the necessary activities take place to complete the work. In today's world, that includes making data available, as well as publishing results in journals and presenting at conferences. All our research activities produce some kind of data. And we are starting to see digital data creation in nontraditional areas, as well as those more familiar research fields. For example, we have dance professors using CGI techniques to map the movements of dancers during performances and then analyze those data using computers. Vast amounts of research data that we produce today need to be managed from creation through to publication. And because of the diverse nature of research, we have communities of researchers needing technology and data management support that do not necessarily have mature data management practices in the field. Our goal is to ensure for our respective institutions that our research data will be consistently collected, adequately documented and quality controlled, analyzed using techniques appropriate for the research question and field of study, and ultimately published in a way that makes them fair. That is findable, accessible, interoperable and reusable. Consequently, it makes sense to recognize that research data management is a fundamental part of the research cycle and support that activity at the institutional level. In order for us to provide effective support, we need to understand what our researchers need in the way of technology and data management support and to engage with them early in the proposal development phase, so they're educated regarding the services we provide and to be able to budget for those services if needed. Arizona State and Penn State have been developing collaborations in a number of areas, because we recognize the value of sharing ideas and leveraging our efforts so that we don't have to do the heavy lift alone. This working group was set up to explore how we might collect the information you need to provide timely and cost effective data management and technology support to our respective research communities. So my name is Matthew Harp. I'm the Research Data Management Librarian and Director of Research Data Services for the ASU Library at Arizona State University. I'm going to provide some use cases our library team experienced this past year that the data needs form could help improve. They include last minute proposal support requests, research data not ready for publication at the time of submission, and the need for boilerplate and cost information at a large institution. Within a week or two from the due date of a grant proposal, we typically will receive a referral for help on a research data management plan, and it is generally clear from the content that the team had not apparently looked over the requirements of the proposal, such as a one to two page limit, nor are they answering the questions the reviewers will actually be looking for. They may be repeating information or provide a narrative out of scope of the proposal such as partnership information and background that is well better left the supplementary information, or sections of their proposal. In many cases teams are not aware of the level of support available to them. They may be unaware of the Office of Research Data Management, the library research support team, or the DMP tool, and thus they are missing out on guidance and general advice linked to the funder's requirements after providing initial feedback on a recent request. A proposal grew in pages, rather than trained to the two page limit. The situation demonstrates a lack of awareness of support and an unfamiliarity with what information the proposal reviewers will actually want. So in addition to socializing our work with our researchers we hope this form builds better awareness of institutional support options and corresponding needs so that we can adapt our work. So integrating into the proposal development process should be an adaptive and flexible and address the funding agencies requests, providing advanced context starts conversations that will help us align resources to the project. So researchers are not having to completely rewrite their data management plan days before it is due. So sometimes data sets are just simply not ready for publication repository services regularly receives data publishing requests when the research data is just in kind of an unstable form. The research project has been completed and now the team needs to share their data per the funder mandate, yet our team has not been informed, despite the repository and our services being actually written into the proposal. So researchers didn't budget for storage. They may not have the appropriate documentation or organize our data in a way that makes sense to the other researchers methodology documentation assisting others and understanding how the data was collected or analyzed maybe missing, or that information might be embedded in a journal article, but they have not provided the basic information directing users to where it lives. This is an unusual and indeed a part of our job is to help them get where they need to be, but this also comes as an unexpected frustration to the researchers at a time that well they're just not ready ready for it. The data needs form brings direct awareness and an opportunity to request research data management consultation services and training for research teams and lab technicians, so that they're preparing to share their data before collection and analysis of data even begins. We also receive requests for a blurb on the data repository, typically at the end of the proposal drafting process real world requests as for boilerplate information or a narrative on the data storage and our repository capabilities. They may even mention that they would like to know how the repository aligns with fair principles and that if a cost is involved to just let them know. We can add it to the proposal, however, even basic cost can vary depending on the nature of the project, and any statement provided should be flexible enough to account for changes to infrastructure and research practices. So the situation is not just about sending over a paragraph to them, but developing a better understanding of their needs. It's difficult for us to provide cost information when we don't have advanced notice of what is coming our way, or we may need to reach out to other support units because we're so large. We need a shared knowledge base to coordinate activities and plan for services that may be months ahead. In the data needs form into the proposal process could allow us to proactively ask questions based on user input and develop a menu of services that could then be added to a proposal for and the budget lines beyond just the storage and backup costs. Hi, I'm Rihanna Wham. I'm a research data librarian for STEM, as well as data learning center manager at the university libraries at Penn State University. The goal in creating the data needs assessment tool is to reduce research or burden by facilitating a just in time single point of entry for researchers to a coordinated research data support service network. In designing this tool, we wanted to create a flexible framework that is platform agnostic and could be adopted and adapted by other organizations based on their needs and the tools at their disposal for implementation. To create such a framework, we first needed to determine what data services to include, acknowledging that the framework will directly impact the form that the tool takes. A major consideration in the creation of this framework was how to make the tool comprehensive, but not too complicated, tedious, or additionally burdensome for researchers. Thus, we developed the framework to be not too far into the weeds, but rather gather enough information to make connections with the vast array of research support services at each of our institutions as navigating these research support services alone can be challenging. Additionally, in designing the framework, we wanted to focus on building a tool that allows for increased crosstalk and collaboration between research data support service providers, as well as transparency of the process for researchers. Throughout the process of developing this framework, we went back and forth on how specific to make search and sections and decided to only add additional information requests where we see the potential for integration with other tools such as the DMP tool or automation between current systems such as our proposal systems. Ultimately, we determined that the framework should touch on data needs throughout the research lifecycle, and so this would include things such as data management, data acquisitions, ethics and legal compliance, storage and backup, and data sharing support needs. We then decided to create a structure that determines sections for researcher review and completion based on their selected data needs. So first, a researcher will see the data needs components, and these include things such as creating or collecting original research data, acquiring research data, data management needs, where the data is being acquired from, storage requirements, as well as information for data transfer and public access to research data. Once these sections are made based on the researcher's needs, a researcher will be presented with some additional questions that then enable us to provide better support. Hi, I'm Doug Dodson. I'm a research computing and data analyst with the Office of the Associate CIO for Research at Penn State University. As we've said, we're working toward a framework that is platform agnostic and flexible. However, we also wanted something more than slides, something that would show that solutions using this framework could be developed rapidly using tools that most organizations like us already have. We created a Word document to capture both the questions we wanted to ask, as well as the form those questions would take on any associated tool. Once we refined our list of questions, we created a flow chart to visualize the branching needed to collect information. This flow chart succinctly and subtly exposes the two primary information related components of our framework, something to present the questions and something to store the associated responses. At Penn State, we decided to create a Power Apps app for our prototype, and at Arizona State, the decision was made to use Microsoft Forms. Microsoft Forms is an example of a tool that many institutions like us already have at our disposal, that is fairly easy to learn, and that has enough capabilities to develop a functional and useful prototype. Power Apps requires a higher level of licensing, and takes longer to learn, but has a robust set of capabilities that could eventually be leveraged to develop a much more capable tool. Microsoft Forms and Power Apps gave us the tools we needed to show different ways for presenting our questions. When it came to storing the associated responses, Penn State decided to use a SharePoint list while Arizona State uses storage features provided by Forms with the option to export the responses to Microsoft Excel. We've also shown that we can leverage integrations with other tools, such as using Power Automate to send an email notification when information changes in a SharePoint list. Very capable tools have been developed without a requirement for extensive technology or programming skills on the part of the developers. Once our respective prototypes were created, we began to schedule demonstrations for potential stakeholders and users of a research data needs smart form app, and we collected their feedback as part of our process to continually improve our nascent framework. It's important to emphasize that we feel strongly that our framework will ultimately support information capture tools from paper forms all the way to high end web applications connected to a back end data store. Once we thought our prototypes were ready, we reached out to a broad spectrum of groups and individuals to schedule demonstrations and discussions. Research administrators, IT staff, researchers, librarians and leaders of sponsored programs offices and research institutes. Basically, anyone who is heavily involved in interactions with research data. These demonstrations have gone well. Feedback includes points and questions such as focus on return on investment, especially what researchers will get in return for the time invested in providing details on their data needs. Communication across the various service providers who could be impacted is critical. Can we connect this with other tools and services such as DMP tool and IRB processes to help streamline them? How do we ensure proper groups are notified and that actions are being taken on the information provided? So what have we learned from this exercise so far? One, we have discovered that the challenge is larger than just understanding data management needs. There are other types of support that investigators require during the life of their grant. We should think about how we understand those requirements and address those too. We originally thought we might integrate this effort into our proposal submission system, but we have realized that actually we need to engage earlier as part of the proposal intake or development process. We now understand how engaging early to understand technology needs can trigger other meaningful discussions about research data management. These discussions have the potential to improve the final outcome and the quality of the data products that investigators produce. We also recognize that researchers will need to see the value add in this process if they're going to take the time to provide the information we ask for. These are all good lessons and as we continue to develop a better understanding of how to support our university's research efforts, we're also developing the tools and processes that they need to be successful.