Working with researchers to establish longer-term paths for the use of ACI capabilities for specific research projects, as needed. Following-up with researchers proceeding through a plan. Working with ACI resource providers for expertise and to accommodate necessary technical solutions.

1. Introduction
2. Goals & Organization of ACI Plans
   2.1 Organizing the Approach
   2.2 Creating Actionable Tasks & Milestones
3. Communicating ACI Plans with Researchers
4. Utilizing other Other ACI Staff
5. Regular Evaluation

Introduction

Often, when working through an engagement meeting with a researcher, it will become apparent that multiple steps will be required to achieve their end goals. To capture the requirements and major steps of taking the researcher from the engagement meeting to a realized research product that utilizes key cyberinfrastructure components for scaling and acceleration, an Advanced Cyberinfrastructure Plan (ACI plan) is necessary. An ACI plan’s purpose is to capture all the general or specific goals and then break those down into actionable tasks and possibly a rough timeline. The ACI plan can be thought of as a document for project management that can be to be utilized by the researcher and the ACI team. While developing a plan the Facilitator should keep in mind that this is a partnership and both sides must be invested in achieving the end goals. It should also be noted that not all engagements will result in a formal ACI Plan as some resolutions will be as simple as issuing a ticket or emailing a researcher.

In this section, the concept of the ACI plan will be further defined and discussed along with some implementation best practices.

Goals & Organization of ACI Plans

An ACI plan provides a framework to incorporate ACI resources into a researcher’s workflow. To this end, an ACI plan serves to:

ACI plans can be formal, in the form a defined document with multiple sections and details, or can be informal, as in many cases, involving only email (perhaps ticket-based) correspondence to captures details for a researcher, after an engagement. The design and makeup of the ACI plan is primarily up to the ACI team, since they will be responsible for executing or coordinating most of the tasks involving ACI resources. Keep in mind that ACI plans can also be used for spotting researcher needs, whether it be the need for additional education, capacity or a different type of resource that is not currently being offered. When creating a new ACI plan with a researcher, a Facilitator may run across tasks or requirements seen in previous plans, and may leverage the same approaches and staff involvement. In this case, it may make sense to combine efforts for a particular portion of multiple ACI plans, this will also ensure that an overarching solution is more generalized across domains and potentially more reusable in the future.

Keep in mind that a major goal of the ACI plan is to establish a path by which your ACI team will be able to have the largest positive impact for the researcher in the most effective timeframe that is plausible.

Organizing the Approach

There are a number of typical issues that a Facilitator may address with a researcher which should be kept in mind when co-creating an ACI plan, including knowledge gaps, technical roadblocks, resource access issues and lack of expertise. To that end, these topics are discussed to illustrate common areas your team should focus on during and prior to an engagement. Note that not all areas will be relevant in regards to generating an ACI plan many will fall primarily into one focus.

Education of researcher

A sustainable means of aiding a researcher in accelerating their research with ACI resources is to establish a set of training materials on how to access and utilize fundamental pieces of ACI. Materials can be disseminated in face-to-face meetings, on websites, or at workshops and seminars provided by Facilitators or external presenters. Anytime an individual can be empowered with the ability to find the solution, new avenues of capability open up for the researcher; this may also free up human ACI resources to focus on more challenging tasks. A few examples of this are:

Additional ideas and training recommendation can be found in the Education and Training chapter.

Identifying and Resolving Technical Roadblocks

Depending on the research needs and the institution, your team may run across more mundane obstacles in the completion of a research project. Storage quotas, network bottlenecks and firewall access are a few common examples. Even when your team is not responsible for basic infrastructure at your institution, Facilitators are encouraged to serve as a liaison between the researcher and responsible technical department to help resolve the roadblock. This liaison role can be pivotal in moving along the research project because ACI team members often have more technical knowledge of issues such as networking or storage than the researcher, and can better communicate with IT professionals on technical issues.

Connectivity and networking issues are frequently hurdles. For example, the ability to move around very large datasets in a reasonable amount of time is a hurdle that many of the current ACI-REFs have run up against. Often, working with IT professionals at our institutions, or at the institution with whom the researcher is collaborating, is the proper route to resolution. So keep in mind some of the basic network bottlenecks, but be aware that there may be technical issues you are unaware of if you are not tied directly into your IT department; a discussion with them should be a priority when dealing with these issues and could save you a lot of running around.

Another issue that is cropping up more frequently is the management of data. A terabyte of data is no longer uncommon for intermediate and even end results of computer simulations and bioinformatic analyses. The minutiae of managing all this information can slow down researchers who just want to get their work done. However, they are the responsible stewards for their research products and their data use may be governed by their university’s Institutional Review Board, their grant’s Data Management Plan and/or other regulatory policies and legal restrictions. By keeping this in mind, the ACI team can create a list of viable solutions that can be leveraged to help the researchers with the influx of data, be they local or offsite.

Access to external resources

Depending on your institution your ACI organization may or may not have a large number and variety of local resources available. In either case, you will not be able to meet all the needs of all researchers at your institution with only local resources. Therefore it is essential that you remain aware of other resources that are available, both those in other organizations at your institution as well as the national resources established specifically for this purpose by by granting organizations. If you are not aware of many of the most frequently used option you can find a list in the ACI Knowledge chapter or on the ACI-REF website (http://aci-ref.org/). Keep in mind that getting access to these resources is only half the solution as the other part is actually enabling the researcher to utilize them effectively.

Partnering with others

As you identify ACI and research needs that go beyond the scope and expertise of the researcher and your team, you will often need to partner with other departments and entities. Your team should not be adverse to this, as some areas of expertise take years to acquire; it is also another way to scale your interactions, if the partner is willing and able to assist in a way that contributes to the end solution. A good set of pointers and ideas for collaborating with other groups is outlined in the Connections chapter. For ACI plan purposes keep in mind the groups that you might frequently need to work with work to establish and maintain those interactions/partnerships.

Creating Actionable Tasks & Milestones

The major step in the development of an ACI plan is the definition of the actionable tasks and major milestones for in depth projects. As previously mentioned most ACI teams do this in a way that fits with their existing workflows and infrastructures, although some have adopted more robust organization and tracking so that they can use some of the ACI plan for metrics/tracking and reporting. Some quick examples of how an ACI plan can be created:

Spreadsheet or Document Method

This is simply a shared document or spreadsheet with the necessary fields to capture a researcher’s interactions and necessary tasks. Google drive, Dropbox, Box, Office 365 as well as wikis are some examples of ways to make these documents easily shared and accessible for a group. Each plan may have it’s own sheet, with the goals at the top and the rows for tasks, which may be checked off or colored to indicate some level of progress or completeness. The benefit of using a shared document is that it is lightweight and easily accessible to anyone; and hosted sites require no local infrastructure for support. Additionally, these documents can be accessed via URLs from other documents. There are shortcomings of this method, however: Documents can become unwieldy if you have many plans or researchers contributing; searching can be a challenge, as can harvesting metrics and trends; and there are rarely built-in notifications or reminders.

Redmine Method

Redmine is a software project management tool with issue tracking, wikis, documents and organizing around projects and subjects built in. The University of Hawaii has been using this method for organizing their ACI plans. Individual projects can be created for the various research projects and the wiki can be used to capture the requirements and other items. Tasks can be broken down into project issues and organized into particular milestones. One of the advantages of Redmine is that is has user, role based access so a researcher can be given access to the project to view progress (if they desire). Time tracking is also supported, which is useful for seeing time invested on a project or necessary for chargeback to grants or billing in some cases.

REDCap Method

REDCap (Research Electronic Data Capture, http://project-redcap.org/) is an tool for building and managing online surveys and databases. The Center for High Performance Computing (CHPC) at the University of Utah has set up a project in REDCap in order to track user interactions as well as to administer user surveys. While other methods (see Basecamp, below) are used for complex ACI Plans that require steps and/or the involvement of multiple ACI staff, the REDCap project is useful when the interaction is between the Facilitator and researcher. In order to use REDCap, the individual project must be designed. At CHPC the project was designed to pull in the user demographic information from our databases given the user ID or name, to allow for multiple interactions and also for notes on the interaction.

Basecamp Method

Basecamp is a commercial tool (see www.basecamp.com) for project management licensed by the University of Utah. It allows for the definition of projects and “to-do lists” which include task lists, task assignments, and due dates. Basecamp also has the ability to post comments and updates as well as to upload files have discussions centering about a given project. A history of a given to-do list is available as are all records associated with completed projects. CHPC uses this tool to manage internal projects, including those associated with working with a user or user group.

Ticket System Method

This method just leverages an existing help ticket management system to capture actionable tasks. It should work well for a team that already uses it for task tracking. Depending on features it may or may not be possible to have documents internal to the system but most systems support urls in tasks description or comments so it would be possible to link url documents for google drive or some other cloud storage document system. Most ticketing systems support tags and searching so tracking some activities and metrics would likely be simpler than the spreadsheet method - many systems do have built in reporting as well. Some examples of ticketing systems in use are JIRA, Redmine, Request Tracker and osTicket.

Jump to: top

Communicating ACI Plans with Researchers

Once an ACI plan is created and vetted by your team, you should present it to the researcher and solicit feedback. With simple, informal plans, an email that outlines the tasks and responsible parties for each task is sufficient and the above tools will not be required. For more complex projects a more formal presentation is necessary, ideally in a meeting, where it is easier to capture additional questions and ideas from the researcher. Organizing the ACI plan into a few slides or a single physical document for easy review is recommended for a formal presentation or, if you are using a project management system like Redmine, walking through the project’s roadmap and issues is prefered as it introduces the tool and interface to the researcher. Be aware that the manner in which you introduce the ACI plan can impact your credibility and the impression of professionalism that researchers will have towards your group. Additionally, remember to communicate who is responsible for what tasks, as well as which tasks will depend on other tasks. Finally, establish expectation for the time-frame in which individual tasks occur versus the estimated end date for solution success. In our experience as Facilitators, we have found that it can be difficult to estimate completion times for certain technical tasks, and so we recommend overestimating times and then (if possible) delivering early. In addition, if the completion of the tasks will be delayed, keeping the researcher updated and informed is crucial.

Jump to: top

Utilizing other Other ACI Staff

In constructing ACI plans, it will often be necessary to solicit advice from others and to depend on their expertise when you are trying to identify appropriate solutions: You, the Facilitator, are not expected to know everything. When you run into those situation be sure to utilize your network of contacts from various fields and ACI resource centers. The Interfacing with ACI Providers chapter has some pointers on how to establish contacts and initiate collaborations. Just keep in mind that your team is not alone in devising solutions, just as you are not responsible for providing all ACI services or resources.

Jump to: top

Regular Evaluation

A solid best practice in managing interaction with researchers is to check in at certain intervals to follow-up on the progress of ongoing engagements and ACI plan implementation as well as following up to evaluate the success of completed implementations.

For ACI plans in-progress, the team should internally review the projects every week and perhaps review with the researcher once a month. However, this all depends on the workloads of both your team and the researcher, and the amount of progress that has been made. At the very least, sending periodic updates to communicate that work is on-going never hurts.

A good time to follow up on completed ACI plans is around eight weeks after completion. At this point the researcher will have had time to work with the solution and might have additional questions or thoughts. After that, a follow-up every six months is a good idea as the PI’s research may have evolved or they may have started a new project. Being proactive is always a good practice so that you can prepare for and anticipate need.

Jump to: top