Many sponsors accept proposals electronically rather than on paper today. The mechanism involved generally falls into one of two broad categories:
- Sponsor provides a website that collects data and uploads, then combines these as they deem appropriate to constitute the proposal.
- Sponsor provides a mechanism to accept an XML (or EDI) data set comprising the proposal information, which is then submitted via a secure internet connection. Sponsor generates a final proposal from the data.
Other approaches exist, such as emailing a completed set of forms to the sponsor, for example, but these are not often used for research proposals of any substantial size due to mail system limitations and concern over viruses in attachments.
Regardless of the method, the goal remains for the proposal to be at the sponsor in the specified format before any established deadline, just as it was in the days of paper submissions.
When submitting via paper, meeting the deadline is often primarily a PI responsibility. They are responsible for collecting institutional approvals and then copying and shipping the proposal off so that it arrives prior to the deadline. In the world of electronic submission, some portion of that burden is shifted from the PI to others. And, perhaps most important, the PI has little control of many things that can go wrong in the portion of the process for which others are responsible. S/he cannot stand at the office door of the internet to get its attention!
Because institutions bear a proportionally larger share of the burden for ensuring that proposals get to the sponsor prior to their deadlines, institutions should actively evaluate and plan for the risks associated with that burden.
In the case where sponsors provide a website to collect proposal information, the additional institutional risk is relatively low – review and approval of the proposal on the sponsor’s website requires internet access and even in the event the campus internet connection fails, folks can often go to a cafe down the street (or home!) to find an active connection and complete the submission.
In the case where sponsors provide a system like the US Grants.gov model, users work on their proposal in a forms package rather than directly on the Grants.gov website. There are significant advantages that accrue from the cross-agency coordination required to implement an approach of this sort. From an institutional risk management perspective, however, the US Grants.gov approach complicates things significantly. Now what needs to be tracked is an electronic file – the Adobe forms package – rather than a paper file. The package has to be stored centrally or passed around via email, tracked to know who has the latest copy with all changes intact, and all users must use a supported version of the Adobe Reader software lest the package be rendered unusable. Because the forms package is cumbersome to use, many institutions have taken on the additional responsibility of filling it out for the investigator. Finally, what previously was limited to being an internal process of identifying signing officials has now become an external process. Individuals designated with Institutional signing authority have to be registered with Grants.gov (and institutions have to have a DUNS number and be registered with the Central Contractor Registry).
The US Grants.gov system, however, represents a huge stride forward in supporting institutions by providing for system-to-system submission capability in addition to the Adobe forms package submission method. This allows institutions to collect proposal data directly into their own internal systems, such as InfoEd, which then generate an xml package to send (via the internet) to Grants.gov in a manner functionally similar to how the Adobe forms package works. InfoEd provides a generic proposal building framework that can be used not only for Grants.gov electronic submissions, but also for other sponsor’s proposals. Thus, a consistent interface can be leveraged for all proposals, which simplifies training and can allow institutions to put some control back in the hands of the PI and his/her staff.
Ultimately, however, once the PI completes the proposal package there is usually an electronic review process followed by a system-to-system electronic submission procedure. Desktop computers, operating systems and software packages, institutional networks, internet connections, Grants.gov’s systems and agency systems all have to work in addition to the people doing various jobs like reviewing the proposal. Institutional risk is heightened – not only is the PI’s control limited, but much of the control and associated risk is out of the hands of research administration staff as well. As with many aspects of our lives, the IT department has become a key player.
This partnership between research administration and IT is relatively new at most institutions. IT staff are experienced in thinking about things like electronic security, system redundancy, disaster recovery and so forth that are key to providing a sound electronic research administration system. These have traditionally not been significant concerns for research administrators. IT staff, on the other hand, lack familiarity with the complexities of varying sponsor requirements and deadlines that are the bread and butter of research administrators.
Risk management planning is not owned by either research administration or IT, however, if research is an institutional priority, then having a sound risk management plan in place is critically important. The scope of a risk management plan for research is, of course, much larger than just proposal submission and includes consideration of animal facilities, laboratories, research subjects, data security and so forth. However, having a plan in place to ensure that proposals can get submitted on time and in the proper format is where it all starts.
A sound proposal submission risk management plan must take into account the kinds of things that can go wrong – like hardware failures, network failures, software limitations, and so forth. Factors such as these can manifest locally at one person’s desk, in a building or campus-wide. The whole internet can be affected. Sponsor systems, including portals such as Grants.gov, can be offline or performing poorly. Some sponsors are flexible when their systems are affected, others consider deadlines firm regardless. A risk management plan for proposal submission should be built around the least flexible scenario – those sponsors who consider deadlines to be inviolate.
InfoEd PD can help with some aspects of implementing an institutional risk management plan. Leveraging sponsor deadline data pulled from SPIN when a PD proposal is created, for example, InfoEd’s routing tool offers the option to alert users at the time of proposal submission to route when the number of days to the sponsor’s deadline is less than a specified amount. This could be used to notify the user of special requirements or expectations due to the short timeline. Likewise, reporting alerts can be configured based on proposal deadlines to alert users or administrators of proposals in development that may have short timelines.
End users need to be educated regarding proposal submission requirements, potential failure points, and options – or lack thereof. Ultimately, the key is to get the proposals completed and submitted earlier so that even if there are problems, they can be resolved such that deadlines are met. Software limitations and problems are notoriously difficult to plan for, as are network failures and construction activities that accidentally cut the internet access pipeline for the campus. If the campus network is notoriously slow, then more time must be built into the process to support moving around large files. Similarly, in the event that there is a network or software failure, time is required to solve that problem. While more time is the ultimate key, backup plans to handle certain scenarios are appropriate. These might include, for example, keeping a list of local cafes with internet access, having a plan to send key staff elsewhere or home to work, or establishing a timeline for fallback to Adobe forms in the event of system-to-system difficulties.
The details of a risk management plan will vary from institution-to-institution reflecting the many differences between those institutions. Factors such as proposal volume will certainly factor into decisions. For example, institutions that submit a large volume of proposals on an ongoing basis will find it more cost effective to implement hardware redundancy than a small institution that can more easily switch to using Adobe forms on a local computer if there is a network or system problem. The key is to think about these issues in advance so that in the event of a problem, a plan exists that can be activated rather than coming up with a solution on the spot.