bulletWhat is a "module?"

In Coeus, the word "module" refers to a (more or less) self-contained section representing certain functional needs in the grants management life cycle. For example, all the tools and screens and windows associated with award maintenance fall under the award module.

Here at Purdue, we use most of the Coeus modules, but not all of them. Since the majority of our post-award activity is handled through SAP, the modules used have primary focus on pre-award and regulatory. Those are:

• Proposal Development and Budget
• Institute Proposal
• Negotiations

bulletWhat do these modules do, and who uses them?

Proposal Development and Budget
By far, the majority of the people at Purdue using Coeus use the Proposal Development module. This is where a proposal starts, where you create detailed budgets and even upload the proposal itself in the form of electronic attachments. The nice thing about Proposal Development is you can pretty much do whatever you want without any consequences to the system or to university reporting. You can create a new proposal, decide it's no good, and just forget about it, or you can continue to edit a single proposal continuously until routing for approvals.

Institute Proposal
They might seem similarly named, but the Proposal Development and Institute Proposal modules serve very different purposes. Unlike the consequence-free environment of development, the Institute Proposal module is the university's official record of proposals that are submitted to sponsors. This is where we run our statistical reports on all pre-award activity, so data integrity here is very important. Anybody can view information in this module, but only a few people in SPS are allowed to update it.

Of course, since they both hold proposal data, the two modules look fairly similar. The biggest difference is that Institute Proposals don't carry detailed budgets, but only summary budget information. The other difference is that the two modules utilize completely different numbering structures where Proposal Development is purely sequential and Institute Proposal uses logic in it's structure.

This is where we track the progress of all contract negotiations with sponsors, both before and after a proposal is submitted (depending on the situation). As with Institute Proposal, anybody can (and is encouraged to) look at this information, but only contracting staff in SPS will record activities there. Since this is all kept very up to date and all communications with sponsors are thoroughly recorded, the Negotiations module is an excellent way for anybody to check the status of an agreement.

IRB (Institutional Review Board)
The IRB module is where information about human subject research is maintained, and it is, for now, the most separated of the modules we use at Purdue. IRB Protocols are created and maintained in this module. Additional functionality includes the ability to generate protocol related correspondence letters that may be distributed to Investigators and meeting schedules/agendas for administrative tracking purposes.

bulletHow do they all relate?
At a very, very high level, information starts in Proposal Development, then goes to Institute Proposal, then (if a proposal is funded) moves on to the SAP grants management module.

Add some more detail to that picture and you'll get...

  • The electronic "routing and approval" process between development and Institute Proposal,
  • The Negotiations module attached to Institute Proposal,
  • The IRB module "sort of" attached to proposals,
  • Certain "behind the scenes" elements that touch everything, such as sponsor data, and
  • Data going to the Business Warehouse for reporting purposes.

Put those all together and you get something like this:


A few key points

bulletRouting and Approval
This is how a development proposal becomes an Institute Proposal. Coeus is designed to include all the relevant people in this process, so everybody who needs to sign off on a proposal can do so before it goes to the sponsor. The system is fairly flexible about applying logic to determine who should see a given proposal, and of course people can override the system's first guess… but for the time being, we won't be using this functionality at Purdue. That decision was for many reasons, but here are a few:

  • SPS review must come first. For the department heads and deans to see the "best" and most final version of the proposal, it would have to have been reviewed by an SPS account manager beforehand. Currently, SPS is not sufficiently staffed to provide the kind of detailed analysis necessary for this. Our current approach of letting SPS do their review after the so-called "unit approval" won't work well in Coeus because, if SPS needs to change something on the proposal, it has to go back to the drawing board… which means it has to get those approvals all over again.
  • Routing rules are complicated. The logic for determining who should approve a proposal can be pretty complex, and while Coeus allows for some flexibility, it's not quite enough to match all of the rules we use at Purdue. This is not an insurmountable challenge, but it will require some patience on everybody's part to get it running smoothly and accommodate all of the tricky situations that may come up.
  • Coeus is not intuitive enough. Routing a proposal would require approvers, such as deans and department heads, to actually use Coeus to indicate their approval. Coeus is many things, but user friendly is probably not of them. Until there is a more intuitive and accessible interface for approvers to use, we can't realistically expect them to approve a proposal in the system. This functionality is coming soon in the form of a cleaner, more user friendly Web portal for Coeus, so that approvals can be done with simple email and a Web browser. We will probably have this tool by 2008.

bulletNegotiations and the "Proposal Log"
In reality, every negotiation is associated with a proposal. As far as the system is concerned, though, a proposal isn't official until it goes out to the door to the sponsor. That is why the Negotiations module is only partly linked to Insitute Proposal. For those negotiations that start before the proposal goes out the door, we create the negotiation record separately (using this proposal log tool), and link it up with the Insitute Proposal later, after it has been created.

Most Business Office staff don't need to worry about this distinction, and they certainly don't need to worry about the proposal log. For more information about this, check the section on creating a new negotiation.

The IRB module has a "soft" link to the pre-award modules, meaning that protocol numbers are hand-entered on a proposal and not directly linked to the IRB protocol in Coeus. This is mostly because human subjects are not the only type of special review that occurs, but also this is because creating a "hard" link between the two would really only affect a handful of people… and it would probably just make things that much more complex for them.

One thing to note, though, is that the IRB module uses many of the same "behind the scenes" information, such as Purdue employees, sponsors, units, and the Rolodex.

Purdue University, 610 Purdue Mall, West Lafayette, IN 47907, (765) 494-4600

2014 Purdue University | An equal access/equal opportunity university | Copyright Complaints | Maintained by Sponsored Program Services

If you have trouble accessing this page because of a disability, please contact Sponsored Program Services at