University of Washington
|Search |Directories |Reference Tools 
USER Project

The Grant and Contract Initiative

GCI Suggested Initial Scope

Purpose of this overview

Current requirements and other analysis documents are written to provide an understanding of an entire, big-picture, ideal-conditions system component (e.g., Budget UTG's recommendations, which describe all aspects of the budget process in full complexity). These do not necessarily lend themselves to viewing system development in a phased manner. This document takes a high-level view of major areas of the system, with priorities and also suggestions for phasing in individual requirements one piece at a time.

This document is not a technical evaluation. It expresses the idea of what users might consider to be the "core" functionalities within each system component, which ones might be essential for user acceptance right away, vs. which ones users might be willing to live without as components are improved with each new release. It will be necessary for GCI developers to review and assess this scope from a technical and feasibility perspective; all items listed below are only suggestions, negotiable depending on the needs of the project.

The columns (which have been changed from "release 1" and "release 2" to "soon", "later" and "much later" to differentiate them from a real project plan) represent broad categories of timing suggested to be acceptable to users. Within each column, the components listed could be divided even further (e.g., column 1, "soon", could represent functions which are phased in during small releases 1, 2 and 3 before proceeding to column 2, "later", with release 4 or 5) depending on the development and scheduling strategies used.

Suggestions by component

1st Release 2nd Release Later

BioSketch/CV

Maintain & link to downloadable BioSketch form template(s)

Users create own BioSketch documents using templates and attach on personnel user interface (UI)

Question: which file formats will we support, and how will we convert them for PDF printing?

Look into central storage for previously-used BioSketch documents, with separate system & UI to select & re-use in other proposals

Questions: how long will we keep documents around, and how will we control access to them, if at all?

Question: will Commons XML/EDI require that we move BioSketch text into GCI system?

Other Support

Maintain & link to downloadable Other Support form template(s)

Users create own Other Support documents using templates and attach on personnel UI

Question: which file formats will we support, and how will we convert them for PDF printing?

Look into central storage for previously-used Other Support documents, with separate system & UI to select & re-use in other proposals

Questions: how long will we keep documents around, and how will we control access to them, if at all?

Question: will Commons XML/EDI require that we move this functionality into GCI system?

Research plan ("science")

Maintain & link to downloadable continuation page form template(s)

Users create own research plan documents using templates and attach on a research page UI; users can specify correct sequence for files, if attaching more than one

Question: which file formats will we support, and how will we convert them for PDF printing?

Consider support for additional file formats

Look into Table of Contents and page numbering

Question: will Commons XML/EDI require that we move this functionality into GCI system?

Abstract

Separate data fields for UW & sponsor abstract in GCI system

Users can copy text between fields

Question: how will we validate for NIH formatting compliance?

Look into policy change on UW/sponsor format differences

Look into specian character & format handling; we will need to follow Commons' lead

Access control

ASTRA; need to authenticate twice, once upon entry to GCI and once upon entry to Ariba

Suggest preparer/PI/reviewer access only for this release

Question: how do we ensure that users only need to enter authentication data once?

Look into expanding access to entire proposal by other users

Question: how will we specify who those other users are for each proposal?

Look into specifying visibility & editability differently for different users

Consider editability rules after submission

Accessibility

Design according to UW guidelines; don't implement any known non-accessible features

Test with assistive browsers

Look into adding additional features to facilitate use by asistive browsers

Output

Work with Commons on XML research; hold off on implementation

Print PDF documents, no Table of Contents or page numbering (can test without this, but must have for go-live release)

Question: how will we convert attached files from native formats?

Consider Commons XML/EDI implementation

Look into Table of Contents and page numbering

Routing & approval

Use Ariba R&A capabilities:

  • Display status in Ariba
  • Reviewer email and preferences functions from Ariba
  • No automatic escalation
  • Push back to GCI system when R&A process is complete

Look into defining approval roles within GCI system and pushing to Ariba (or possibly combination of both); use Ariba rules to set order of roles within approval graph

Look into displaying status in GCI system (outside of Ariba), adding automatic escalation functionality

Look into generating approval graph in GCI system & pushing into Ariba

Consider replacing remaining Ariba functionality in GCI system

Look into generating custom "pre-review" approval graph for partially-completed or separate sections of proposal

Budget

Model line items as parent class with subclasses for personnel, nonpersonnel and subcontracts

Automatically copy new entries to all forward years (but not backward)

Pull salary/wage/benefit information from UW financial systems; determine "calculated base" salary/wage according to B-UTG's rules. Allow user override of base salary to accommodate raises & manual inflation settings (but no automatic inflation)

Provide link to graduate student rates in helpfiles

Create & populate indirect cost rate lookup table; suggest set up single indirect cost rate per proposal in this phase; find out whether initial release can work without ability to define custom rates

Integrate cost sharing with budget line items; collect source information for each item

Create & populate budget category map(s); write business logic to apply MTDC exclusions by category where appropriate, including subcontract IDC

Calculate subtotals by category, total personnel, subcontracts direct/indirect, total direct, MTDC, total indirect, total sharing, total costs, sharing % of total costs, for each year and all years

Maintain & link to downloadable continuation page form template(s) for justification

Users choose whether to enter justification text in form field or create own justification documents using templates and attach on budget UI

Apply various inflation rates

Copy specific budget items from one year to another

Set up multiple indirect cost rates using location data (preponderance & ratio methods)

Create & populate graduate student compensation lookup table

Calculate cost sharing subtotals by source

Set target totals amount for individual year and/or all years; validate that totals add up; display difference

Set up sub-budgets for APL, center grants, program projects, & subcontracts; if OMB compliance issues are resolved, make sub-budgets available for multiple indirect cost rates also

Select & adjust budget line items to satisfy target total

Personnel

See personnel scope document

For PI "personal data," no boilerplate initally

 

Look into designing full personnel profile (for NSF) and include PI boilerplate data at this time also

Proposal details

Create & populate lookup table of sponsor information, sub-agencies & institutes

Collect preparer contact info

   

Performance sites & Resources

Create & populate lookup table of performance sites; allow new entries

Collect facilities & resources descriptions

Question: associate indirect cost reates with locationa?

   

Yes/no questions

Create & populate lookup table with question text (for maintainability & GCS compatibility), but identify question-related rules and a way to keep rules separate from data structure

 

Implement additional (long) list of NSf questions (see EDI spec)

User help, human guidance, training

Single help link leading to a topic index

Support via email; contacts as defined by GC-PET

Bug reporting dB and web page for testers & users to enter

Context-sensitive help links on each page leading to topics relevant to that page

 

General proposal management (entire/all areas)

 

Copy entire proposal to new proposal

 

Protocols

Generate human subjects letter of intent via email; prompt for user OK before sending (at submission time)