Many non-profits live and die by the grant money that they are able to bring in. CiviCRM can currently track incoming grant applications through CiviGrant, but there is no way to track outgoing grants applications.

This functionality has been requested by users of CiviGrant in the past, but the project never moved forward. The organization that I work with is very interested in tracking our grant application workflow, which in turn makes me very interested in implementing this functionality.

After some discussion in the forums, it was suggested that I write up a blog post with a few ideas on how to go ahead with the project. Essentially, I see three options:

1. Extend CiviGrant by adding DB fields.
2. Extend CiviGrant by leveraging activities.
3. Replace CiviGrant with a CiviCase workflow.

Before moving ahead, I would like to gather as much input as possible from the community. While I will obviously be biased toward fulfilling my own organization's needs, my goal is to contribute a useful improvement to the CiviCRM community. If you have any suggestions or concerns, please leave a comment, especially if you already use CiviGrant, CiviCase, or both.

Incoming and outgoing grants can be distinguished by the relationship between the grantor and the grantee.

incoming

An external contact is the grantee (i.e., a constituent), and the your organization is the grantor.

outgoing

Your organization is the grantee, and an external contact is the grantor (i.e., a foundation).

Option 1: Extend CiviGrant by adding incoming grant specific fields

The most obvious way to extend CiviGrant would be to simply modify the civicrm_grant table to hold information about incoming grants as well as outgoing. Some new fields would be required, but some existing fields could be reused. Further, some of those existing fields would change semantics based on whether a grant was incoming or outgoing.

For example, a new field called direction would signify whether the grant is incoming or outgoing, while the amount_requested field could be reused. For incoming grants it would list the amount requested from your organization, and for outgoing grants it would list the amount requested by your organization.

One problem with this approach is you end up with fields in the table that are only applicable to a given record, or whose semantics change, depending on the direction of a grant. You could keep separate tables for incoming and outgoing grants, but then you end up with redundant fields since incoming and outgoing grants share some common characteristics. I think the database folks have a technical term for this, but I just think it's ugly.

Another problem with this approach is that it is very rigid. It does not provide much room for future extensibility, or for customization to fit a particular organization's workflow. For example, my organization would like to keep track of each time an inquiry is made regarding a particular grant application. This naturally leads one to think of activities.

Option 2: Extend CiviGrant through activities

This option is motivated by two key insights:

1. Incoming and outgoing grants share some common characteristics.
2. The differences between incoming and outgoing grants are based mainly on interactions with contacts.

The goal then, is to only store the common characteristics of grants in the civicrm_grant table and track the interactions with those grants in some other way. This will require adding some fields civicrm_grant, modifying some fields, and removing some fields.

Furthermore, the information that was previously stored in removed fields must be recorded in some other way. Since that information essentially descibes an interaction with a contact, it naturally lends itself to recording as an activity.

New fields

name

a descriptive title for individual grants

direction

binary field to denote incoming / outgoing

grant_application_due

could be rolling deadline specified by NULL value

Modified fields

grant_due_date

renamed from grant_report_due for the sake of consistency

Deprecated fields

decision_date

replace by grant decision activity

applicaton_received_date

replace by grant application received activity

money_transferred_date

replace by grant money transferred activity

grant_report_received

replace by grant report received activity

After these modifications, each of the fields in the civicrm_grant table will be applicable to a grant regardless of its direction. Moreover, they have consistent semantics regardless of direction or status.

New activity types

The deprecated fields from the previous section will be replaced by new activity types. Notice that each of the activity types are applicable to incoming grants, outgoing grants, or both.

grant inquiry

an inquiry was made regarding the status / eligibility of a grant (both)

grant application submitted

a grant application was submitted to a funder (outgoing only)

grant application received

a grant application was received from a constituent (incoming only)

grant decision

a grant decision was made (both)

grant money transferred

grant money was transferred (both)

grant report received

grant report was received (incoming only)

grant report submitted

grant report was submitted (outgoing only)

Migrating current users of CiviGrant

I can foresee two major impacts on current users of CiviGrant.

First, there will be some changes to the UI. My goal would be to keep the UI as streamlined as possible, and preserve the ability to enter a new grant -- as well as any associated activity -- using a single screen. This is an area where I would really appreciate community input. What works with the current UI? What does not work?

Second, there should be an option to migrate data from deprecated database fields to the new activity types. The migration should be a seamless, one-click bulk operation. Moreover, it should performed on-demand by the user. While I would love to simply delete the deprecated fields and migrate the information automatically, I realize that this would not sit well with many of you! However, the deprecated fields should eventually be removed and the migration forced in some future release.

Advantages

The nice thing about this option is that it leaves a lot of room for flexibility, depending on a particular organization's workflow. For example, multiple inquiries can be recorded, or none at all. Custom activity types can be created easily.

It also lends itself to future extensibility. For example, grants for a particular campaign or pool of funding could be grouped easily using tags. A ranking system could be established that prioritizes grants based on the strength of an application or the likelihood of receiving funding.

Option 3: Replace CiviGrant with a CiviCase-based workflow

The activity-based extension to CiviGrant described above has obvious similarities to CiviCase. Therefore, it might make sense to pursue a CiviCase-based workflow instead of "reinventing the wheel".

Like Option 2, such an approach would involve creating new activity types. It would also require creating some custom fields to go with those activity types (e.g., to record the amount requested, amount granted, etc). The difference is that the custom data would be associated with an activity, while in Option 2 the information would be associated a grant. Some custom reporting would also be required to perform any accounting functions associated with grant applications.

My main concern with this approach is that CiviCase has a very complex workflow, which might make it overkill for the grant use-case.

In order to avoid having two components (CiviCase and CiviGrant) that duplicate each other's functionality, the CiviGrant module should be deprecated if this option is implemented.

Conclusion

At this point, I am leaning toward Option 2. As you can probably tell just by reading this blog post, it is the option that I have put the most thought into.

It's not that I want to duplicate the functionality of CiviCase into CiviGrant, but that I want to use a consistent paradigm with existing CiviCRM building blocks to extend CiviGrant's functionality. I think two-way grant tracking is a general enough function for most non-profits that it deserves it's own component.

However, I think pursuing Option 3 would be interesting if for nothing else than the learning experience. Through doing so, I would be in a better position to weight the pros and cons of each option. My staff has alread agreed to becoming guinea pigs, so I will most likely begin to pursue both options in parallel and see which works better for us.

I will report back here as my implementation progresses. If you have any questions or concerns, or would like to help with implementation or testing, please leave them in the comments below. Hopefully this will generate some healthy discussion.