Inside Implementation: What’s involved, and what’s ahead, for the Sponsored Programs module
Contributed by Randy Bickford
In a March blog post, we provided an introduction to the team of professionals currently leading the ERA Project implementation. With the Animal Care and Use module now successfully launched, we’d like to update you on the team’s recent activities and future plans for the Sponsored Programs module — which is next in line for implementation, along with the Conflict of Interest module.
The Discovery Phase
The Sponsored Programs module team is currently in the initial phase of implementation (shown in the figure below as Requirements Gathering and Business Process Mapping). But module team lead Angie Fullington likes to use a more concise term to describe this important first phase: “discovery.”
The goal of the discovery phase, Fullington says, is to begin to map out how current operations will be incorporated into the new system. Fullington and her team will then work with research administration leadership to broaden the scope of discussion to include input from research personnel at the college and department levels.
This process is expected to ramp up over the next few months — so if you have not been contacted yet, fear not. Someone from the ERA Project team will be contacting your college or department soon.
Order of Operations
This approach of gradually expanding to target a wider and wider range of users across campus for feedback is strategic. There are a lot of constraints and considerations to manage. Fortunately, the team members have done their homework, as Sherrie Settle, director of Sponsored Programs, can attest.
Settle has been working hand in hand with Fullington, and she provides a helpful explanation for the order in which the four Sponsored Programs submodules, shown in the figure below as Proposal Tracking (PT), Award Tracking (AT), Proposal Development (PD), and Financial Tracking (FT), will be implemented.
“If you were going to build a new system from scratch, from the ground up,” Settle says, “you would definitely start with Proposal Development as your first submodule.” Every grant or cooperative agreement, of course, begins life as a proposal, so that is the first stage of the sponsored award process.
“But our task is harder than that,” Settle says. “We have to transition all of the existing capabilities of a legacy system like RADAR into something new and better that also does not lose any of that legacy’s system’s existing capabilities that people use and need.“
This, Settle notes, is the main reason for starting implementation with the PT and AT submodules. “For the most part, with a few exceptions, these two submodules will be used by staff at the central office, so there is a much smaller population of users to focus on,” Settle says.
Other campus users will be able to access information in PT and AT, as they do in RADAR, but it is important to ensure that central office users receive in-depth training on the mechanics of PT and AT transactions early on, as campus users will likely look to them for technical assistance later on.
The other two submodules, PD and FT, will be used by a wider community around the campus. So it should follow, then, that the implementation process should move from a narrow to wide target user audience.
The schedule for the submodule rollout, as shown in the figure above, will position the project team to shape the flow of the inevitable deluge of questions and concerns, both specific and broad, that will be received from stakeholders across campus as the process unfolds.
Even at this early stage of the process, feedback from SPARCS and other university central offices has helped the implementation team to identify a number of opportunities for system improvements.
One example will likely appeal to any finance manager who’s ever had to update a vendor address. The new module will consolidate system profiles for vendors and customers so that updates to addresses or other contact information do not have to be re-keyed in multiple places.
Other improvements to reduce redundancy will be found in the PD submodule, which will be much more powerful than the current PINS system. Users will be able to do everything they currently do with PINS — but this new system will integrate the proposal development and submission functions of CAYUSE 424 as well, so users won’t have to double-enter the information.
We can also expect the new PD submodule to integrate with the Human Subjects Research (IRB) and IACUC modules, which should make the pre-award process much faster and smoother.
So when do users get to see what the new Sponsored Programs module interface in the ERA system will look like? The team is working on that.
Earlier this month, InfoEd sent a representative to Raleigh for four full days of system demonstrations and informational, constructive discussions — which are a vital step in the requirements gathering process.
While most of this on-site visit was devoted to kicking off the Conflict of Interest module, a full day drilled into the details of the options InfoEd offers for recording awards, documenting changes to budgets between proposal submission and award, managing incremental funding and deliverables, and other specific tasks in the sponsored programs life cycle. This discovery process complements the business process discovery described above, allowing the team to identify the best combination of business practice and software configuration to meet NC State’s needs.
In some ways, these visits are an extension of the proof-of-concept (POC) demos, which were the final, determining factor in our purchasing decision. The POC demos taught us a lot, but only so much could be covered. During these vendor visits, we’re able to gain a much more in-depth understanding of the system’s capabilities. This allows for the very first iteration of the module — which InfoEd calls a “prototype” — to be developed so that the discovery process can continue.
As the scope of discovery meetings is broadened to include a wider range of users from the university community, the team will use the input gathered to create a working model of the Sponsored Programs module. “We don’t consider this a ‘prototype’ per se,” Fullington says, “Because we’re still going to incorporate lots of input from the university, and this model will go through many different iterations.”
To this end, the module team plans to set up on-site sessions with representatives from the university community to present the model and allow community members to explore and interact with it. To help make the model a familiar digital working environment for early users at these meetings, the project team will import data — such as the names of typical sponsors or vendors — that users use on a day-to-day basis.
Once the working model has gone through a sufficient number of iterations, the module team can move on to the all-important final phase of implementation, user acceptance testing, which we have written about previously on this blog.
Until then, the team will continue its strategic process of gathering information and requirements from university leadership.
For our next blog post, we plan to cover the progress made toward the implementation of the Conflict of Interest module. Continue watching this space and your email inbox for more updates about the ERA Project!