Disaster Recovery Grant Reporting System

Disaster Recovery Grant Reporting System Training for NSP Users

<number>

<number>

<number>

 

Session Rules

• •Ask lots of questions 

• •Set all cell phones to silent or vibrate. 

• •Raise your hand if you are having computer problems or fall behind. We are here to help! 

<number>

2

 

Training Objectives

• •Train NSP grantees on how to use the DRGR system for NSP reporting. 

• •Walk through DRGR screens with grantees so they can better understand the basic steps. 

• •Help prevent common problems with the DRGR system. 

• •Show grantees how to tell their story to HUD. 

2

3

 

Training Schedule

• •DAY 1 

• • –Overview of the System 

  • –Detailed Review of DRGR modules (Action Plans & QPR) and processes 

• •DAY 2 

  • –Review of Day 1 Material 

  • –Detailed Review of DRGR modules (Admin, Drawdown, Reports) and processes 

  • –How to tell your NSP story in DRGR 

  • –Common Issues/Troubleshooting 

3

4

4

 

NSP & DRGR

• •Disaster Recovery Grant Reporting – DRGR – system was developed specifically for disaster recovery grantees.  

• •NSP is NOT a disaster recovery program, but it was critical for HUD to act quickly. 

• •DRGR is relatively easy to update to adapt to changes in NSP 

• •DRGR had basic components needed by NSP 

• •DRGR can customize key components quickly and easily 

• • –Activity Types (i.e. Adding Land Banking as a new eligible activity for HUD) 

  • –National objectives (i.e. LH25) 

  • –Narrative fields  

  • –Performance Measures for grantees by appropriation  

4

This slide discusses why NSP uses DRGR and how DRGR serves the basic needs of the program in terms of a data collection system.

• •The Disaster Recovery Grant Reporting — DRGR — system was developed specifically for disaster recovery grantees to help them manage their grants and receive funding. When you are using the system, keep in mind that you will see some activity types and other terminology designed for Disaster Recovery funding; these should not be used for NSP.  

• •NSP is not a disaster recovery program, but the DRGR system was the best suited existing system at HUD to use for NSP.  

• •DRGR is relatively easy to update and change. As NSP has evolved, HUD has been able to make changes to DRGR and adapt to needs of an NSP grantee. HUD will continue to make adjustments to the DRGR system to meet the data collection and reporting needs of NSP. DRGR users are responsible for staying abreast of these changes. 

• •DRGR allows NSP grantees to track and report the basic components of the NSP grants management process. It was not designed to collect all documentation needed for the program.  

• • •The system allows the grantee to describe the proposed use of NSP funds by creating an Action Plan. 

  • •The system allows the grantee to track expenditures and request NSP funds from its allocation by creating draw vouchers.  

  • •The system allows the grantee to track program income generated and how the income is used for additional eligible activities.  

  • •The system allows the grantee to report accomplishments and progress by adding and submitting quarterly reports to HUD staff.  

• •DRGR can customize key components of the program quickly and easily. For example: 

• • •New activity types such as Land Banking 

  • •National objectives 

  • •Narrative field (as they change per each NSP round) 

  • •Performance Measures 

5

5

 

NSP & DRGR: Updates

Updates included in recent Release 7.3

1. 1.Receipts, Revolving Loan Funds, and Program Income Accounts 

2. 2.Voucher Improvements 

3. 3.Audit Trail, User Account Management, and User Certifications 

4. 4.Miscellaneous Grantee Functions         

5

Given the evolving nature of NSP, DRGR has seen some significant changes over the past year. HUD continues to evaluate the system based on feedback from grantees like yourself and plans on making additional changes to the system in the upcoming year.

DRGR is currently on version 7.3 (as of early December 2011).  When you first log in to DRGR, you will see a “DRGR NEWS” section on the first page. It is good practice to review this information for important updates that could affect your program.

Release 7.3 was the last major release and it included the following updates which we will discuss in detail throughout the day.

 

1. • •Program Income receipts, setting up and using Revolving Loan Funds, and Program Income Accounts. 

1. • •Improvements to Vouchers including documenting the voucher process and making revisions. 

1. • •Audit Trail, Account Management, and User Certifications. 

1. • •Other miscellaneous functions including updates to how the users views some data, the ability to verify address information, and more information is provided in the QPR. 

6

6

 

The Basics: DRGR Modules

6

DRGR is now composed of five major modules: Admin, Action Plans, Drawdowns, QPRs, and Reports. The Admin module was enhanced in late 2010 and is now a more prominent feature in DRGR. Each of these modules will be covered today. Even if you will only work within one of the modules, it is important to understand how the five modules inter-relate.

• •Admin:  Admin module allows the grantee admin users to certify other grantee users and assign them to grants. Grantees can also record any monitoring, audit, and technical assistance (TA) events  they conduct as part of grant oversight. 

• •Action Plans: The Action Plan in DRGR mirrors the information submitted in the substantial amendment sent to HUD.  If the grantee has not yet identified specific organizations and programs, the  activities listed in the amendment may show as projects in DRGR.  The Action Plan may be resubmitted multiple times as new activities are awarded and entered. 

• •Drawdowns: Once the Action Plan is set up and approved, grantees will use the Drawdown Module to obligate funds, receipt program income, and create draw vouchers.  

• •QPRs: As grantees move forward with their NSP grants, they are required to submit quarterly reports to HUD via DRGR. The information reported in the QPR module is key to demonstrating progress – both financial and performance. 

• •Reports: The DRGR system has a comprehensive set of canned reports available to pull information out of the system, including administrative reports, financial reports, and performance reports. Reports can serve as valuable management tools for two main reasons: (1) to help grantees monitor the status and progress of their various funded projects and subrecipient, and (2) troubleshoot issues or concerns a grantee is facing within DRGR. The reports can be viewed online, printed, or downloaded as a PDF or Excel file.  

<number>

<number>

 

Telling Your Story

<number>

• •DRGR is THE place to tell your story to: 

• • –Your CPD Representative 

  • –HUD Headquarters 

  • –Your Citizens 

  • –The wider public 

  • –Organizations and the media who request information on the program’s progress 

8

8

 

Getting Started

Grantee Access to DRGR

DRGR Roles

Testing out the System

DRGR Navigation

8

First, we are going to briefly discuss how to get started in DRGR and the key components of the Admin Module. Then, we’ll login to the system to try out different links and conduct our first case study.

 

 

<number>

 

 

<number>

 

<number>

<number>

 

Access to DRGR

• •Directions located on DRGR Log In page 

http://portal.hud.gov/hudportal/HUD?src=/program_offices/comm_planning/communitydevelopment/programs/drsi/drgrs

1. • –Send request to CPD Field Office 

   • –FO staff reviews and forwards to [email protected] 

• •Default grantee role: Regular User 

• •Must specifically request additional roles:  

  • –Grantee DRGR Administrator 

  • –Request Drawdowns 

  • –Approve Drawdowns 

  • –View Only 

<number>

This slide summarizes the process to obtain a user ID for the DRGR system and some key points to keep in mind when requesting access.

• •A complete set of directions is available on the DRGR Log-In page at http://portal.hud.gov/hudportal/HUD?src=/program_offices/comm_planning/communitydevelopment/programs/drsi/drgrs. To obtain an ID, send an email to your HUD CPD Representative requesting DRGR access. Field Office staff will review the request and forward it to DRGR staff for processing. The email must include the following: 

• • oFull name of user 

  • oGrantee name 

  • oC# assigned for IDIS User ID (if current IDIS user) 

  • oAddress 

  • oPhone, fax, and email address 

  • oWhether you will be the primary DRGR system administrator for your community 

  • oWhether you are authorized to request or to approve drawdowns 

  • oA five-digit PIN number, which will be used by the HUD help desk for help tickets 

• •If the email does not request a specific user role, you will automatically be registered as a Grantee User. This role allows editing of the Action Plan and QPR.  

Financial management roles, such as Request Drawdowns and Approve Drawdowns, and system management roles, such as the Grantee Administrator, must be requested in the email. You will learn the access rights of all DRGR user roles on the next screen.

10

10

 

DRGR Roles: Grantee

11

There are three basic Roles a user may have in the system:

• • •Grantee Administrator - Every grantee will need at least one Administrator 

  • •Regular Grantee User* - When signing up to be a DRGR system user, HUD will automatically default to the Basic Role of Grantee User. 

  • •Grantee – View Only 

In these Basic Roles, you do not automatically have access to Requesting Draws or Approving Draws. You must request that separately. This includes Grantee Admins. Although contrary to what you may think, Grantee Admins do not automatically have full access to all parts of they system. For example, Admins CANNOT request/approve drawdowns automatically. These roles are requested and added separately and do not come with being an Administrator. These roles are not specific to various grants, they are the Requestor or Approver for all grants.

There are two additional roles a user may have in addition to having a Basic Role: Grantee-Request Draw and Grantee-Approve Draw.

1. • •Every grantee needs at least one person with the Request Drawdown role; it is recommended to have at least two in case the primary Requestor is out of the office 

   • •Every grantee needs at least one person with the Approve Drawdown role; it is recommended to have at least two in case the primary Approver is out of the office 

   • •A User cannot have both Request and Approve Drawdowns for the same NSP grant. 

<number>

<number>

 

DRGR Roles: Grantee

This chart summarizes the functions available to each role. The roles are listed across the top in columns and the different abilities are listed along the left in rows.

• •A grantee user will be assigned one of the three Basic Roles: Regular, Grantee Administrator, or View Only. The user may also be assigned one of the two Additional Roles: Request Draw or Approve Draw.  

• •The most limited role is View Only. This grantee user can only view the information in the system.  

• •The Regular Grantee User has view and edit abilities for the Action Plan and QPR.  

• •The Grantee Administrator has view and edit abilities for the Action Plan and QPR, plus the ability to assign other users to grants and to block drawdowns at the activity level. 

• •Both of the financial roles can edit obligation information.  

 

 

<number>

 

 

<number>

 

<number>

<number>

 

DRGR Roles: Grantee Administrator

• •Assigning Users to a Grant 

• • –Accessible from the Grantee Admin Page 

• • • •Only accessible to Grantee Administrators 

  • –When to Use It:  

    • •New User 

    • •Remove a User 

    • •New Grant  

• •Drawdown module functionality 

  • –Block draws from being processed internally  

• •(Re)Certifying Grantees (will discuss in 4 slides) 

<number>

Each grantee must have at least one user assigned as the Grantee Administrator. This slide discusses the tasks that the Grantee Administrator must complete in order for the grantee and its users to have access to DRGR, including assigning users to a grant and certifying grantee users. In addition, Grantee Administrators have the ability to block drawdown vouchers.  

• •Assigning Users to a Grant: It is important for the Grantee Administrator to assign all of their users to the correct grants. If the Grantee Administrator does not complete this step for a user, that user will not be able to view or edit any information associated with that grant. There are several occasions when the Grantee Administrator will need to update a user’s access to a grant:  

• • oThe grantee has a new user. 

  • oThe grantee has been awarded a new grant (e.g., NSP3). Authorized users for one grant, NSP1 for example, are not automatically given authorization to other NSP grants.  

  • oThe grantee needs to remove a user because the user left the organization or no longer requires access to a specific grant.  

 

• •Blocking Drawdowns: Grantee Administrators can edit Activity profiles in the DRGR Action Plan to block draws as they are being processed internally. This allows an additional internal control on a community’s drawdown process, if needed. This is done in the Action Plan at the Activity Level. 

• •Certifying Grantee Users: Before a new user can access a grantee’s information, the Grantee Administrator will need to certify the user. In addition, the Grantee Administrator will have to re-certify all current users every six months.  

13

13

 

DRGR Roles: Grantee Administrator

13

 

Hierarchy of User Certification

<number>

• •With release 6.5, DRGR has added a user certification functionality. DRGR is now required to include certification/recertification of each DRGR users by higher-level users in DRGR. 

• •With release 7.3, the HUD HQ field office managers can now access the HUD Field Admin screens so they can certify grantee admin users if their CPD reps are not available. 

• •And, with release 7.3, DRGR will maintain historical data for each certification and reports will be available to show the history of certifications.  

• •Recertification takes place every six months. If a user is NOT recertified after the expiration period, the user will not be able to access any part of DRGR. When such users log in, they will receive a message that their certification expired.  If a user receives this message, refer back to this flow chart and find the individual who is required to recertify the user.  For most grantee users – this will be their Grantee Admin user. 

• •To accomplish the certifications, we will use the following process involving HUD and grantee staff. The slide depicts the hierarchy of user certification:  

• • •HUD HQ staff will assign CPD Field Managers to Field Offices.  

• • •The CPD Field Managers will then certify the HUD field staff in their offices, including the CPD representative for each grant in DRGR. 

• • •CPD representatives will then certify the identity of the authorized grantee contact (which may be populated from the grant agreement in LOCCS) and the grantee contact will be contacted by email to certify their DRGR grantee system administrators. This is the one part of the process that is outside of the system.  

• • •Grantee administrators will be able to certify/re-certify the remaining users in DRGR using a screen much like the one they use to authorize each user’s access by grant. 

 

 

<number>

 

 

<number>

 

<number>

<number>